At 22:27 +0200 2008-10-14, Marcel wrote:
Is it conforming to the REST philosophy to use key/values in the URL?
http://www.x.com/serv/location?user=joe&passwd=bla&lat=4.132&lon=8.4559
In the message "Re: POST/GET and URL confusion", dated 2008-10-14,
Rob Heittman wrote:
If you have data you need to supply (lat and lon) I would rather use
a URL structure like
/serv/location/{lat}/{long}
or -- I think better:
/serv/location/{space-separated-latlong}
since this does not imply hierarchy where there is not necessarily any.
In Richardson and Ruby's book, RESTful Web Services - also
mentioned in Richard Hoberman's post earlier today - a colon or
semicolon is recommended as a delimiter between value pairs in a URI;
e.g.
/serv/location/lat,long
The authors suggest using a comma where the ordering of the values
matters (e.g. as in the case where, by either convention or
specification, latitude is always written first, then longitude), and
a semicolon where ordering doesn't matter. They write: "This kind of
URI may look a little strange, because not many web sites or services
use them right now, but they're catching on."
Section 3.3 of the RFC for URIs,
http://www.ietf.org/rfc/rfc2396.txt, discusses the specific uses of
the comma and semicolon in path segments in URIs; section 2.2, on
reserved characters, may also be relevant.
This is part of why query parameters in the URL seem simple but
actually end up being confusing. Not that it's wrong, or illegal,
or non-RESTful, or any other pejorative term ... it's just harder to
reason about what is going on. Especially because you may use some
of those query parameters as imperative verbs (action=delete) some
as variables (lat=4.132), etc. Now it is not clear whether you mean
the HTTP verb (GET) or your own verb "delete" ... and it's not clear
whether you mean for me to look at what's in the entity, or what's
on the query string, or both.
A terrific summary - thanks Rob!
Aron
