[Catalyst] REST - like uri design for CRUD

[Thomas L. Shinnick]

At 04:06 PM 1/20/2008, =3D?KOI8-R?B?88XSx8XKIO3B0tTZzs/X?=3D wrote:
> >  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=3Dbreadbox
> >  2)  GET    /class/id/1111
> >  3)  PUT    /class/id/1111
> >  4)  POST /class
>Nice clarification, thank you! But is the "/id/" =

>part of url required? In most cases class would =

>have only one primary identifier, so we can =

>shrink it to GET /class/1111 - can't we?

Oh definitely the naming URI's is very important, =

and can be intricate.  The authors develop on a =

couple different example application cases =

illustrating how they would layout the URI =

namespace.  And how they sometimes have to go =

back and redo the layout to eliminate conflicts.

Their essential criteria are that each URI =

specify one 'thing', and that every 'thing' have =

(at least) one URI.  That doesn't mean that a =

less-specific URI is not meaningful.  If =

"/class/1111" is one item, you might still allow =

"GET /class" to mean "get me the list of all items under /class".

>And concerning case 3 - I think that rarely used =

>PUT method could be replaced with common POST to =

>avoid possible problems with proxies, etc. -- =F3 =D5=D7=C1=D6=C5=CE=C9=C5=
=CD, =F3=C5=D2=C7=C5=CA =ED=C1=D2=D4=D9=CE=CF=D7.

The authors do take care not to be so rigid we =

can't _try_ to approach "the one true way of REST". :-)

They specifically allow that when PUT is not =

available or impracticable (clients, firewalls, =

and proxies can get in the way), you could =

'overload' POST by, for example, adding a query =

parameter "_method=3DPUT" to pass-thru the real =

request method.  The idea is that the handler =

would pick off this parameter and dispatch as =

though the HTTP method had really been PUT.  But =

you try to use this request like you would a =

'real' PUT, in what the data contains and how it is used.

But this is a question I have, whether the REST =

dispatching modules have an capability like this, =

interpreting overloaded POSTs? =

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080120/79305=
338/attachment.htm