Damian Cugley’s Weblog
Does I make sense to rework the URLs for the Picky Picky Game so they more resemble REST-inspired interfaces like the Well-Formed Web experiment? I have belatedly returned to the project and started by creating a self-contained server version (as opposed to the CGI-based one created earlier). This gives me more control over the URL scheme used for the (proposed) site.
I am still expecting the game to work with current web
browsers, so it follows that POST requests will use
the types application/x-www-urlencoded (standard
forms) and multipart/form-data (forms with file
uploads in them), rather than expecting uploaded XML (that can
come in the future, so that people can connect with their
XHTML-2-based wristwatches in 2012).
I am also following the de facto convention for
content negociation, namely .-suffixes on URLs.
For example, we can view index.html as a request
for the resource identified by index in the format
nicknamed .html. With a little fiddling of the
back-end I can arrange that specifying index
also works (i.e., the suffix is optional) so long as the
Accept header is properly formed. By the same
token, you can also invoke the vote URL as
vote.html (‘show me the results in
HTML’) or vote.xml, say (hypothetical, for
now). This is my proposal to do the equivalent of the
type=xml or fl=xml query parameters
offered by some web servers.
The upshot of this is that, hypothetically, the voting procedure—where you are presented with a ballot for choosing which pictures you like in a particular round—should be changed from
/cgi-bin/picky-vote?g=sample&r=10&votes=2&votes=3
to something like
/sample/10/vote.html
With the votes offered as form parameters with a
PUT request, since you are replacing your previous
ballot (if there was one) with the new one. This is all fine,
but I have no idea if web browsers are going to be relaxed
about my specifying a form with method=PUT. Some
experimentation will be required. I may pragmatically have
to accept POST...
Another thing I’m not sure about (in terms of REST) is
that the vote page will show your vote (at
least, the one owned by your IP address), so the same URL shows different
results for different people. Is that kosher? Hmmm. (Of
course using IP as authentication is never going to be
particularly satisfactory.)
Finally, while I may be able to replace
cgi-bin/picky-upload with a POST to something like
10/candidates.html, this request has no choice but
to use multipart/form-data as its format,
XML data cannot carry binary data (such as images).
Update (18 March 2003). Really what I am talking about here is more to do with cool URLs (to use the term coined by Tim Berners-Lee) than REST per se.