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?
Bulk (or batch) operations are used to perform an action on more than one resource in single request. This can help reduce networking overhead. For network performance it is usually better to make fewer requests instead of more requests with less data.
The batch mode allows creating and / or updating multiple elements in one request. Notice the list of resources which supports the batch mode. The results of the different tasks (create / update) is stacked and returns one result. In addition, the batch mode supports the detaching of elements in on request.
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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With