12/14/07 :: [Other] REST and Search [permalink]
Assaf has some issues with my statement:
Perhaps we’re just not talking about the same resources.
This is also a question on GET with respect to “search”, can “search” be modeled in a RESTful way? I am not sure the answer is yes, but that’s secondary
Obviously we’re not talking about the same resources.
I have made this point a few times, without attempting to substantiate it. You probably noted that by now that I like precise semantics, if you want to be sloppy writing code you can, but it will come haunt you. Using semantics for what they are for usually will benefit you. Actually if even the RESTifarians are pretty uptight on some semantics (Verbs or idempotence for instance) -and that's a good thing.
So how come search could not be RESTful? I have been doing a lot of reading recently in the REST documentation. Section 3.2.2 of the RFC2616 specifies how the HTTP scheme is used to locate resources:
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
There is a query there, but it is not specified anywhere else in the HTTP spec. The spec does however says:
since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time.
So they are definitely different than your average network data object (a.k.a one of the two types of resources identified by the HTTP/1.1 specification). This is not sufficient to prove this is not a resource, since there are legitimate resources which value can't be cached (e.g. stock quotes, obviously Yahoo does not treat them as resources because I have to refresh my browser cache now and then -thought that Yahoo was a model for RESTifarians?).
Before you jump on your keyboards to reply to this post, let's continue the exploration. I know you are going to tell me that the URI is just a bunch of characters and the results return by the query is a "resource".
So let's take this argument that "the resultset is a resource". As I see it, there is a real difference between adding an element to a collection and adding an element to a result set. A collection is a resource, a result set is not. What would it mean to "DELETE" a resultset resource? What would it mean to PUT and POST? you mean I could change the content of the result of a query without acquiring the "resource representations" first? How are the semantics of returning a single resource versus a collection of resources defined? What is actually the structure of the resultset collection when there are more than one? This structure is defined nowhere, it is ad hoc.
The other problem introduced by "search" is that I can find an infinite number of URI to address to a resource (using a (true) | (false) predicate). The HTTP spec says, using more than one URI should be avoided. Since "U" does not mean unique but uniform, we are ok, but the fact and the matter is that if by mistake I create a link to a resource using a query URI /person?nickname=JJ, what happens if this value changes? well the link is broken. At the end of the day, query-URIs destroy the notion of identity which is so critical to the resource concept and to the web at large.
So for me, guys, the "resultset" IS-A "resource" argument is very tenuous. It is more an I-SAID-SO-IS-A relationship.
Sorry for splitting hairs, but semantics is what information system construction is all about.