<html>
<body>
<font size=3>At 04:11 PM 1/20/2008, Ashley wrote:<br>
<blockquote type=cite class=cite cite="">On Jan 20, 2008, at 1:33 PM,
Thomas L. Shinnick wrote:<br>
<blockquote type=cite class=cite cite="">At 01:56 PM 1/20/2008, Zbigniew
Lukasiak wrote:<br>
<blockquote type=cite class=cite cite="">/class/search<br>
/class/id/1111/view<br>
/class/id/1111/update<br>
/class/create</blockquote><br>
<spew register="pedant"><br>
One important topic in the book is that people mix 'verbs' into their
URIs when they shouldn't, or at least when they don't _have_ to.
Using the book's concepts your URIs would become<br><br>
1) GET /class?pattern=breadbox<br>
2) GET /class/id/1111<br>
3) PUT /class/id/1111<br>
4) POST /class<br>
</spew></blockquote><br>
Clipped a bunch. This is great food for thought. I am missing in this
scheme how you would know to serve the form for updating. That seems to
be the real point of /class/id/1111/update. I suppose that should be
/class/id/1111/edit instead and it would, if it could, properly PUT the
form to /class/id/1111, yes?<br>
-Ashley</font></blockquote><br>
Rats, I can't pinpoint the area where they talk about this (serving
forms) in the book. Two points of departure:<br><br>
First, there is a difference when talking about how you go about
implementing RESTful interactions where both the client/server are
programmed, that is, where data is exchanged directly and people aren't
involved. When you instead want to make accommodations for allowing
more classical (non-Javascript) interactions it _does_ get cloudy.
And if you want to serve _both_ programmed and human interactions it gets
positively foggy. You don't want to start having alternate URIs
just to specify what 'kind' of representations to serve.
So...<br><br>
Second, if there are multiple representations for an item, how do we
specify which representation is being requested? The authors ask
that you try to use something like the Accept: header, so that a
Javascript program can specify that it wants an XML or JSON
representation, _rather_ than an HTML form representation. If you
want to allow plain unenhanced browsers you could serve the form in HTML
by default. But if the request specifically said give me straight
data, the server would see the "Accept: application/json" (I
think that's right) and respond with "Content-type:
application/xml". Program or person - the HTTP headers tell
you which.<br><br>
Now they again mention real-world hiccups, where some component might not
pass-thru or pay attention to headers like Accept. They offer that
you could (if forced) specify the desired content type in either the
query parameters or even the URI itself, where they suggest an
extension. Thus "GET /class/1234.xml" would be what a
program might request, rather than a plain "GET /class/1234"
which might default to HTML.<br><br>
Basically they keep coming back to the same theme: use HTTP to its
fullest, both headers and methods (e.g. PUT), and much becomes possible
that otherwise seems clumsy. (Didn't say 'easy'...
:-)</body>
</html>