What is the correct way to do a get for multiple resources (batch get) with REST?

Question

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?

Answer 1

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.

Answer 2

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:

• Maximum length of HTTP GET request is limited but configurable
• Using POST for GET's is not a shame, but for sure an anti-pattern

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