Re: Quixote 3

On 3/17/06, mario ruggier <[email protected]> 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&section=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 <[email protected]>
([email protected] address is semi-reliable)