On 3/17/06, mario ruggier  wrote:
> 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 ;)

When you've dealt with situations where you wanted to count the number
of hits per article but can't because the query strings weren't stored
in the logs, it becomes a lot less academic.  There *is* a difference
between parameters that identify a page vs those that are extra
information.

> For example, i wouldn't know how to formulate a restful URL to modify
> the identifier of an object?

You don't modify the identifier.  Identifiers are never supposed to
change, like a primary key.  That's why it's better to use an
arbitrary ID number rather than somebody's name.  If you really have
to modify the identifier, you might as well use a POST, which means
"make an arbitrary change to the application".

> 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?

I don't know; I haven't dealt with languages.  I wouldn't go this
extreme with REST.  The user should obviously set their language once
and the system should remember it.  Whether that's in a cookie,
session, or permanent user record, isn't going to make the sky fall.

> 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.

I don't believe in using Javascript unless necessary.  Kludging
Javascript because your application requires PUT sounds ridiculous.
It may be necessary in some circumstances; e.g., interacting with a
WEBDAV library that you can't modify.

--
Mike Orr 
(mso@oz.net address is semi-reliable)