A
A
arturgspb2013-01-21 21:54:53
API
arturgspb, 2013-01-21 21:54:53

Filtering in GET in RESTful

Hello! I have been tormented by the question for a long time:

let's say the application has a REST api, let's say it supports requests like this:

GET /rest-api/models/?idModel=1,2,3,4,5,6,...

Suppose the method returns information about product models whose identifiers are specified in the request.
We all know that getting information on each model separately is not cool, so a group request is just right.

Problem
What if there are too many id-shnikov in the get request, or they are ten-digit in my application - not so much can fit in GET. It turns out, for the sake of RESTful principles, should I degrade performance? It seems to sound like nonsense - the same POST request that has id-shniki in the body will be much cooler.

What will the public say?

Answer the question

In order to leave comments, you need to log in

4 answer(s)
E
EugeneOZ, 2013-01-21
@arturgspb

It turns out, for the sake of RESTful principles, should I degrade performance?

Yes. Performance has never been REST's forte. The time taken to open a connection is often much higher than the response time. For performance, use RPC.
the same POST request that has id-shniki in the body will be much cooler

Make no exceptions in the standards. Then such a monster will be built from these crooked pieces that it will be impossible to support it. Because “here it’s like in the standard of such and such, but only in a different way, so this must be remembered and it is not compatible with standard tools and it’s better not to touch it without documentation.”

A
Alexey Huseynov, 2013-01-21
@kibergus

In a POST request, it will not be cooler. caching will not work.
A more curious question is whether processing N requests to get objects is actually slower than processing 1 request to get N objects. Provided that the client sends all requests through one HTTP connection, and the server uses persistent connections with the DBMS. If the objects are heavy enough, the extra overhead can be small. Now if we take into account that the caching granularity has increased and the client will not request the same object twice, it may turn out that N requests will work faster. And if the client and server support SPDY and the requests go not sequentially but in parallel, then at the cost of increasing the load on the server, we can get a decrease in response time. Now a low response time seems to be appreciated.

A
Alexey Huseynov, 2013-01-21
@kibergus

There is another interesting question: why did the client need to request many models from the server by ID? What unites these objects? This is some entity that is on the client, but which the server does not know about. Perhaps it is worth introducing this entity and the problem will disappear.

M
Michael, 2013-01-21
@1099511627776

Try to stuff them in headers

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question