On Mar 17, 2006, at 4:08 PM, Mike Orr wrote:
On 3/17/06, mario ruggier <[EMAIL PROTECTED]> 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.
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
