Database search with a RESTful Web API

Question

I am quite new to REST, but what I want to do is implement a (not that simple) search function to my API. I want to search a database using multiple keywords (eg author, booktitle, ...) and different search operators (eg ~, =, !=, ...). What I'm looking for is something like a convention, an example or a "best-practice"-tutorial how to do this in an elegant way in terms of routing parameters etc.

EDIT: Basically I want to know how to include the operators belonging to each keyword in the URL in a nice way.

Answer 1

First check the URI template standard. If it is enough for you, and you can solve your problem with multiple links, then you got luck.

If not, then you have to send back some structure description about your search queries. First you have to choose a query language. It is probably better to choose a standard query language, so you don't have to create a new one. After that you have to send back some semantics (probably in RDF) about the constraints of your search queries. For example you can search for words in the articles titles and order the results by dates, and so on... this kind of stuff... So the client can generate the query using the details of the query language, the constraint descriptions and the user input.

After the query was synthesised by your client, you can send it in the following formats:

• GET /blah?q="query details" - the query string serialized in a single query param, (the query language can be anything)
• GET /blah?query=x|details=z - using an URI query language
• SEARCH /blah ... - sending in the SEARCH body with the proper MIME type (the query language can be anything, but be aware that caching is probably not supported by the SEARCH method, because it is an old webdav method with not maintained standard)

So the key problem that we don't have currently a standard or an RDF vocab to describe the query structure for the client, and thus sending a query link will probably violate the self-descriptive constraint and couple the client to the service implementation. (By most of the current APIs the client reusability and fulfilling the REST constraints is not a concern.)