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.
Don'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.
I'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.
Or 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.
This 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)
