At 04:11 PM 1/20/2008, Ashley wrote:
On Jan 20, 2008, at 1:33 PM, Thomas L. Shinnick wrote:
At 01:56 PM 1/20/2008, Zbigniew Lukasiak wrote:
/class/search
/class/id/1111/view
/class/id/1111/update
/class/create
<spew register="pedant">
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
1) GET /class?pattern=breadbox
2) GET /class/id/1111
3) PUT /class/id/1111
4) POST /class
</spew>
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?
-Ashley
Rats, I can't pinpoint the area where they talk about this (serving
forms) in the book. Two points of departure:
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...
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.
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.
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'... :-) _______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
