Hi again Marc,
The "Restful Web Services" book published by O'Reilly (
http://oreilly.com/catalog/9780596529260/) is a very good resource for
understanding REST principles.
The use of the query string in and of itself does not make an API RESTful or
not RESTful. But the main point of RESTful web service design is to create
web services that leverage the architecture of the WWW. This means taking
advantage of the features built into URIs and how web infrastructure (user
agents, caches, proxies, load balancers, newfangled "layer 7 switches")
understand these semantics.
When the query string variable in question identifies an addressable
resource, particularly when that identifier is part of a hierarchy, the path
part of a URI is likely to be the most logical mapping. This is how regular
static file resources on a Web site work; "/foo/bar/baz.html" incorporates
the IDs of two folders and a file, respectively.
So your question works equally well when inverted: "Can you give a practical
example when you NEED to put an id in the query string?" Wouldn't it seem
unnatural to fetch the file above by going to
"/files?folder1=foo&folder2=bar&file=baz.html" ...
Sometimes the idea that everything should be done in a query string comes
from the historical accident that the only way to make a web service used to
be to create a CGI or server-parsed script file, which a web server
executes, and by reading query string parameters, the script decides what to
do. In a RESTful web service paradigm where you have broad control over the
URI space of your service, there's no reason to care about this. Rails and
Restlet are good examples of such environments.
For a Web service interacting with content in a database, these hierarchical
identifiers might be anything, perhaps:
/channel/{channel-id}/article/{article-id}
e.g. /channel/movies/article/17124
or /channel/4/article/baz
This *can* functionally follow all the same REST style principles as a query
string based API that looks like this:
/server?channel={channel-id}&article={article-id}
... but there is something a bit more logical, intuitive, and navigable
about the path form in this case. Especially if one can request a channel
listing (an index) from /channel, an article listing from
/channel/{channel-id}/article, etc.
There is ambiguity and associated waste associated with using query strings
as resource identifiers:
/server?channel={channel-id}&article={article-id}
/server?article={article-id}&channel={channel-id}
In typical query string use, both of the above URIs probably refer to the
same resource. (Making it order sensitive would be against convention,
though not illegal).
But caches will store them separately, and it is difficult for code to
reason about the effects of, say, PUTting the first and then GETting the
second. If there are optional parameters or default settings for
parameters, substitute "difficult" above with "impossible."
Because of this ambiguity and the prevalent use of query strings in
applications where the delivered content is purely dynamic, many
implementations treat URLs containing a query string differently from URLs
which do not. This can lead to unexpected behavior or poor performance,
usually a failure to cache things you expect should be cached.
But not every problem maps well onto a hierarchical URI path space, and
there is nothing overtly precluding an API from using query strings and
still leveraging REST principles. So there ARE indeed times when you would
actually want to use query strings. There is even an interesting "Matrix
URI" concept that Restlet has support for (although most user agents don't
currently support it) which introduces a matrix URI space as well as a
hierarchical one.
But typically, using query strings for identifiers in a RESTful API is often
a warning that you're not ideally leveraging the architecture and semantics
of the WWW, so REST developers sometimes go to great lengths to avoid it.
That said, I'm not sure I fully understand what your correspondent is
trying to do, either.
- R
On Sun, Jun 8, 2008 at 11:02 AM, Marc Larue <[EMAIL PROTECTED]> wrote:
> having id's in the path makes no sense to me... what is the argument that
> REST provides for this? And can you give an example of a practical example
> when you need to put an id in the path and where an id in the query
> wouldn't suffice?
>
