tags:

views:

129

answers:

4

I would like to implement a REST service which is able to parse query such as retrieving the users created after startdate and before endate and with the privilege of admin. It seems that standard REST implementation could only query by ID. Do I need to self-defined protocol to make this kind of query possible or any standard?

Thanks!

+1  A: 

As far as i'm concerned - restful stuff is valid for CRUD actions. You can implement separate search method/url and pass it as many parameters as you need. And if you still try to adhere to REST methodologies - you should use GET request type.

Eimantas
+2  A: 

There is no constraint in REST that says you can only query by ID. There is absolutely nothing wrong with using a set of query parameters to return a set of users that match those search criteria.

Darrel Miller
A: 

Ryan Bates has a Railscast where he shows creating searches as a resource. The concept is still valid, even if you're not doing Rails.

http://railscasts.com/episodes/111-advanced-search-form

Steve Klabnik
+1  A: 

Take a look at Google's GDATA Protocol. It's very RESTful and they have a very nice way of performing "complex" queries while still keeping a clean URI.

http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries

Here is an example of what their clean query URIs

http://example.com/jo/-/Fritz/2006

instead of

http://example.com/jo?category=Fritz&category=2006

From Google:

This approach identifies a resource without using query parameters, and it produces cleaner URIs. We chose this approach for categories because we think that category queries will be the most common queries.

nategood
I think it is a nice way, but it cannot satisfy all the situation.
xiao
True. But it gets you in the right mentality. URIs should be thought of as IDs and not queries. Don't think of your query in terms of a search string or SQL, rather think of it as an ID identifying a resource (which itself maybe is set of other resources - hyperlinking is a big deal in REST).
nategood
I beg to differ. A *query string* in a URI is exactly for the purpose of querying. It doesn't make the approach of per-query URI invalid, on the contrary, it can have advantages, especially around caching. So does POSTing a complex query and issuing a redirect. It all depends on your needs, and none of the solutions are inherently unrestful.
serialseb
Wasn't implying that there is anything wrong with having a query string in a URI. Just proposing GData as an interesting, different way of thinking about URIs in search. I was trying to emphasize thinking of search results as ID-able resources and that search results should promote hyperlinking. Yes, the ID/URI can contain whatever and the structure of the URI makes it no more or less RESTful/cacheable. Never mentioned POSTing a search request for obvious reasons (overhead of a POST request, lack of caching, goes against HTTP's definition of POST).
nategood