[Catalyst] REST - like uri design for CRUD

[Thomas L. Shinnick]

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'... :-) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080120/86f587c3/attachment.htm