Re: Quixote 3

On Mar 7, 2006, at 11:05 PM, Mike Orr wrote:

> Yes.  It means that the record identifier comes before the action,
> like in OO programming or a GUI menu.  It also means that both are
> encoded in the URL path rather than in query parameters, so that there
> is a bookmarkable link to every record and every action.  Examples:
>
> /article/1234/                     # Default action is view.
> /article/1234/?print=1    # Options are allowed.
> /article/1234/edit              # Another action.
> /diary/2006/03/06             # A 3-part record ID.
> /incident/333/666/            # Show entry 666 of incident 333.
> /incident/333/666/delete # Delete the entry.
> /incident/333/add_entry # Add an entry

Thanks for these explanations and the links below.

I totally agree with the reasoning that GETs should be for requests, 
POSTs for modifs, etc. About restful URLs, as in your examples above, I 
am not so convinced though. It gives off a little whiff of academia 
nuts ;)

For example, i wouldn't know how to formulate a restful URL to modify 
the identifier of an object? Assuming that an application allows this 
-- it implies modification of an attribute on the object, with some 
delicate overhead. For example suppose I'd want to change the entry id 
666 to 667 in your example above? Should that be therefore done with a 
PUT? But, if the application takes care of all the implications of 
changing a key for the object, semantically it is not a PUT (no object 
is replaced!). A PUT is also a lot more complicated than a 
set_attribute(), i.e. a POST to modify the one attribute.

Another question is about how to handle such things as language. In 
restful URLs you are expected to specify everything in the URL, thus 
not relying on any state information, whether in cookies or sessions. A 
cookie may be used _only_ to identify a user session. So, should all 
urls include 'en' or 'fr' etc somewhere? And where should it be? At the 
beginning, at the end, between the last object identifier and the verb, 
as a query string parameter? Or is it acceptable to have this 
information to be remembered, so if I send a URL for a resource (that I 
read in english) to my japanese friend, shouldn't she be automatically 
shown the japanese version?

And yes, It is annoying that support for non-GET HTTP methods is not 
consistent. About the fact that one cannot do a non-GET from a link, I 
guess one can easily kludge a generic piece of js such that clicking on 
a link will cause the submit of a form on the page, thus giving a cheap 
way to get POST, PUT (maybe) and DELETE (maybe) from a link. At a price 
of having some additional javascript, thus will only work within a web 
page context, and one that has js enabled.


> REST also implies defining the behavior for each HTTP method, and
> denying requests that are inconsistent with the method.  GET requests
> should be repeatable (idempotent); they should not modify data
> destructively.  POST requests may modify data in a non-repeatable way.
>  PUT and DELETE should be used to replace or delete a static file (or
> whatever the application considers a static resource), rather than
> POST.  I don't bother doing this because having an 'if' switch in
> every callable is cumbersome, you can't count on browser support for
> more than GET/POST, HTML doesn't expose all method everywhere (you
> can't do non-GET hyperlinks), the method set isn't comprehensive, and
> hiding destructive behavior behind POST forms is reasonably safe
> enough because no hyperlink will contain the magic submit parameter.
>
> This explain REST pretty well.
> http://ajaxpatterns.org/RESTful_Service
>
> Here's a RESTful application spec.
> http://wiki.openstreetmap.org/index.php/REST