On 3/17/06, mario ruggier wrote:
> >> 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 ]
This is really a rename, which HTTP doesn't have a verb for. Or it's
a delete followed by a put. Changing an identifier defeats the basic
purpose of identifiers. If it must be done, a POST sounds like the
most reasonable way to do it.
> 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...
I suppose we should leave REST at this point and talk about our own
guidelines. I'm not a REST expert, and I'm interested in REST only
inasmuch as it encourages human-readable, intuitive URLs. I don't
even remember why they are so against state, other than that you have
to keep it consistent if you scale to multiple servers. My own rules
are:
/container/contained/specific_item/action = good
/view.php?article=1234§ion=foo = bad
cookies containing user preferences = good
state kept in session objects = good
state kept in database records keyed by session ID = good [1]
[1] Some people prefer this to avoid maintaining session data in a
different format than their other data.
--
Mike Orr
(mso@oz.net address is semi-reliable)