4 ms·
What about a RESTful API where you pass in a list of IDs to retrieve from the server? You'd want to use a GET so it's idempotent but I can't see how you'd make
by adamauckland 14y ago
What about a RESTful API where you pass in a list of IDs to retrieve from the server? You'd want to use a GET so it's idempotent but I can't see how you'd make an exceedingly long list of IDs without using a data payload underneath the GET statement.
- darrhiggs 14y agoDon't do it that way then. How about a using /queries collection? You could create a query there and have the server return a link to the results using the 'location' header.
- mnarayan01 14y agoOr you could just use a PUT request with the ids in the request body. I get the reasoning behind doing it with a POST -> GET, but doing that as a default case would be nuts. If nothing else either I can a) DOS you trivially or b) you might as well use PUT because the result URI is going to be far from permanent.
- adamauckland 14y agoThis is probably the most correct response. It still bothers me that because GET can't take bulk parameters I either have to use a PUT or spool many GETs (which still isn't as fast as one GET)
- Dylan16807 14y agoI'm looking at this suggestion and somehow it seems like the exact opposite of the intent of REST. You're looking at a query that doesn't make any changes on the server and trying to figure out how to do it. Then you run into the fact that GET is incapable of passing bulk data the way the other verbs can. And instead of being slightly misleading by wrapping what is a GET at heart inside a POST, you would rather make the query cause changes on the server just so that it uses 'POST' correctly. You're taking a clean, standalone query and perverting it into a dirtying one.
- philjohn 14y agoonly request a subset at once?
- adamauckland 14y agoCan take a while over a slow mobile connection