14

Is it:

GET api/stuff?ids[]=123&ids[]=456&ids[]=789&ids[]=101112&etc...

is it:

POST api/stuff/batch
  body: ids: [123, 456, 789, 101112, etc]

?

The first seems semantically correct, but aside from having an incredibly gross url, there are sources that say there's potentially a limit for the length of a get, so what if I have a gazillion ids?

The second seems better because there's no gross url, but my understanding with rest is that a POST is supposed to be making a change, not be idempotent..

So is this purely a semantic issue and there's no true "correct" way?

treecoder
  • 43,129
  • 22
  • 67
  • 91
patrick
  • 9,290
  • 13
  • 61
  • 112

3 Answers3

10

I would use POST, because of this:

POST requests are never cached (by browser)
POST requests have no restrictions on data length

read more: HTTP Methods: GET vs. POST

Also POST, GET were defined before REST. So it's not a shame to use (sometimes!) POST for some read-only requests.

EDIT:

After some years, I have to revise my answer.

Today I think that neither GET nor POST are good solutions for the real problem. At least, there is no final solution here, it depends...

First some facts:

Then you should definitely clarify, what is the source of this ID-list, where do the ID's come from? This certainly has some business case.

I would try to move the source of the ID's, or the logic how the ID's are created to the backend. Once this is done, the REST endpoint "get for multiple resources" is unnecessary.

So the message is, try to eliminate the need for such REST calls und when you can't use GET

alex
  • 8,904
  • 6
  • 49
  • 75
6

There is no one "correct" way, it really depends on the REST server's particular requirements. However, in the case of a GET with a query string, it could likely look more like this instead:

GET api/stuff?ids=123+456+789+101112+...

Or like this:

GET api/stuff?ids=123,456,789,101112,...

Or this:

GET api/stuff?ids=123|456|789|101112|...

Whatever delimiter the server wants to use.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
6

As with many things in REST, it is not always possible to be purist.

One solution is to flex the definition of what a resource is. Then, getting multiple resources is itself a resource.

POST can be idempotent if that's what's best for your APIs. It's just that PUT should always be idempotent, while POST can afford to not be. Just document the endpoint properly.

You can allow to accept the IDs from both GET and POST. Then depending on how many IDs are being sent, the client can choose either. Just document it properly.

The guiding principle is how easy to use and consistent your APIs are. Understand that making APIs is a UX problem.

treecoder
  • 43,129
  • 22
  • 67
  • 91