Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 203
patrick Avatar asked Mar 21 '16 23:03

patrick


People also ask

CAN REST API handle bulk data?

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.

What is REST API batch?

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.


2 Answers

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.

like image 137
Remy Lebeau Avatar answered Dec 08 '22 00:12

Remy Lebeau


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

like image 37
dieter Avatar answered Dec 08 '22 00:12

dieter