views:

368

answers:

1

I want to build a RESTful web service that implements a search interface for a database of biological data.

A typical search request could involve a dozen or so attributes of the data. For example, search by scientific name, constrain the search to water depths less than 100m. My first instinct is to have all of the attributes in the query string e.g. ?searchType=sciname&sciname=mola+mola&maxdepth=100&mindepth=0

However, query strings are considered non-RESTful, see http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful

I have looked at some earlier SO discussions such as http://stackoverflow.com/questions/207477/restful-url-design-for-search and I'm still not clear on this point, so my question:

Is there an accepted standard or pattern for RESTful URLs for a search service where there may be an arbitrary number of filtering values?

+2  A: 

In the REST style of the Web:

  • The path component of the request-uri identifies a particular resource.
  • The query-string component of the request-uri identifies any particular filters or alterations done when presenting that resource.
  • The Accept header identifies a particular content-type in which the given resource, filtered as specified, should be presented.
  • The Accept-Language header identifies a particular language in which the given resource, filtered as specified, should be presented.

So to answer your question:

GET /species?searchType=sciname&sciname=mola+mola&maxdepth=100&mindepth=0

is perfectly appropriate.

Justice
I agree that the query string is an appropriate place for his search parameters, but I don't agree with your URL example of `GET /search` - search is a verb, which isn't all that RESTful.
Rob Hruska
Changed to `/species`, because this apparently a bio-related app.
Justice
Cool, that sounds better. I'm still wondering about his 'searchType' parameter. It almost seems unnecessary. I'm awaiting the OP's response to my comment on the question.
Rob Hruska
Yes, it may not be necessary. I didn't want to get into that simply because the most important part was to explain the way one requests a resource, and how one requests the resource to be filtered, in the REST style.
Justice
I was not too clear on the base url portion because I was focused on the query string. /species is what I was contemplating. However I was going to have two versions: one for a simple retrieve of all records for a species and one for a filtered request. For example:/species/mola+mola ... return all records/species/mola+mola/filtered?maxdepth=100,numrecs=1000 ...filter on depth and number of records returned