What is the best way to create RESTful complex queries?

Question

Hello,

What's the best way retrieve complex queries from a REST service?

Suppose I want to get X collections, apply filters and equations to each one, combine the collections using some other operation and return one result, everything in one request.

It is just too complex (and big) to put everything in the querystring since I could combine more than 300 collections (plus the operators and filters to each one).

I thought about using POST to send a XML object describing the query to something like:

http://mydomain/collections/complexQuery

It would return an unique ID and then I could use GET to retrieve the complexQuery result:

http://mydomain/collections/complexQuery/{queryId}

Jason S:

That's the idea. The POST will take an XML representation of the query, with the "where" parameters already (they can be too many). The query will be executed only when the GET arrives. I could let the query object available just for some time and delete it later.

Is this a good solution? Am I still RESTful doing this?

Answer 1

This is the standard RESTful approach. POST to the resource and expect a 202 Created (no entity body) with the URI to the created results in the Location header. You can also return the results with a 200 OK response, and optionally a URI pointing to the results for future (de)reference in the response along with a copy of the results.

Answer 2

Sounds RESTful to me if you're using a unique ID. If the query result set is large you might want to include a way of asking for result set rows M - N where M,N are parameters.

I guess an advantage of your unique ID approach (w/ query definition state stored on the server) is you could use the result of the query as a parameter of another query. Maybe even separate out POSTING the definition of a query from the execution of the query.

Answer 3

Does that mean that searchparams are going to be stored on the server side.Opens up new reqs to clear the params periodically and lot of other complexities?Is this the right way for handling complex queries?

Answer 4

It is OK. But it introduces a few problems:

1. You have to persist the query data on the server, when do you clean old queries?

2. If you clean old queries, it means you can't provide links to saved queries because they might have been already cleaned.

3. Even simple query requires two round-trips (POST & then GET)

4. Your client needs to be familiar with the XML schema you expect, instead of the well known: param1=val1&param2=val2

Answer 5

sorry, my ignorance...

but why not just returning the data with the post???

I can understand why it's wrong to update data with a get, but I don't see why it should be mandatory to update data with every post?

I also understand that the idea is that every get method could be potentially cached (because they don't modify data), but in this case they could only be cached if the temporarily saved query is still active... which adds another layer of complexity...

I also thought that one of the principles of rest is to define stateless (like the http protocol) interfaces, and in this case the server is maintaining a state to solve the query...

I've just started reading about rest and there area several things that I just don't yet understand...