At 04:06 PM 1/20/2008, =?KOI8-R?B?88XSx8XKIO3B0tTZzs/X?= 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=breadbox
> 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. -- ó Õ×ÁÖÅÎÉÅÍ, óÅÒÇÅÊ íÁÒÔÙÎÏ×.
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=PUT" 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? _______________________________________________
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/
