...
- Accepting GET requests with a single query parameter. (That query parameter may often be named 'q=', 'query=', or 'search='.)
- Accepting GET requests with a multiple query parameters.
- Using a GET request to retrieve an XHTML advanced search form, which the client can then submit to the service via a POST request. See Mark Baker's November 2006 comments on the atom-syntax list.
- Creating a new resource within a collection of searches, populating that resource, and activating it, perhaps by POSTing it to an active searches collection, or by retrieving its "./results" child resource.
Also of interest:
...
A variation on the last approach is suggested in Rich Apodaca's comment on the question "RESTful URL design for search" on the Stack Overflow Q&A site:
... you could make Search a first-class resource:
POST /searches # create a new search
GET /searches # list all searches (admin)
GET /searches/{id} # show the results of a previously-run search
DELETE /searches/{id} # delete a search (admin)The Search resource would have fields for color, make model, garaged status, etc and could be specified in XML, JSON, or any other format. Like the Car and Garage resource, you could restrict access to Searches based on authentication. Users who frequently run the same Searches can store them in their profiles so that they don't need to be re-created. The URLs will be short enough that in many cases they can be easily traded via email. These stored Searches can be the basis of custom RSS feeds, and so on. There are many possibilities for using Searches when you think of them as resources. The idea is explained in more detail in this Railscast.
Also of interest:
...
To conduct a "simple" search using default assumptions ...
Query parameters:
q= or query=
REST-based APIs for Relation (Association) Services
...
Leonard Richardson and Sam Ruby, RESTful Web Services
Michael Mahemoff, et al., RESTful Service - Ajax Patterns
...