On Mar 17, 2006, at 4:08 PM, Mike Orr wrote:
> On 3/17/06, mario ruggier  wrote:
>>
>> 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.

Ah, yes, good example. I guess for GETs, however "un-REST" the URLs
are, you get the possibility to do what you say anyway. But for POSTs,
it would be nice to have the article id in the loggable URL for the
modify request...

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

Well, primary keys may be modifiable, and I am just trying to
understand how such a request would map to a REST URL. If one does a
POST for something like this, how do you express it in a RESTful way?
Maybe it is not an issue actually, as doing in the POST URL the changed
value is anyway not included in the URL, e.g.

POST /article/333/666/modify
[ postData: id=667 ]


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

Yes, that's my point... where do you stop?
What are the guidelines to what should not be in the URL?
The claim that cookies should *only* be used to identify/authenticate
the user seems extreme...

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

JS has its place for sure... I agree that maybe this is not one of them.