Re: [rest-discuss] An approach to deleting multiple resources use one DELETE
- At Mon, 6 Apr 2009 15:29:32 -0600,
Eric J. Bowman wrote:
>If you don’t think so, then you don’t think that your application is
> Erik Hetzner wrote:
> > ‘Uniformly defined for all resources’ means *all* resources on the
> > web, e.g. anything addressable using a URI which is part of the
> > web’s global hypertext infrastructure.
> I don't think so. When designing an API, my concern is only those
> resources I control. Since methods like PUT and DELETE have variable
> semantics, it's impossible for all resources on the Web to have
> uniformly-defined semantics. REST may be seen as an architectural style
> consisting of constraints imposed upon the Web architectural style,
> i.e. HTTP is not REST.
part of the web.
Of course when designing a web API you can constrain the semantics as
you like (as long as it is *more* specific than HTTP). For the web as
a whole, HTTP methods have the semantics described by HTTP - no more,
> > There are no application boundaries in terms of method semantics.So you are saying you do not believe in a uniform interface? We need
> > DELETE means the same thing everywhere. It can’t mean one thing
> > for one URI which happens to be part of one application and
> > another thing for another URI which happens to be part of another.
> > The semantics must be general enough that it means the same thing
> > for all URIs.
> Strongly disagree. In HTTP, PUT may mean either create or replace. In
> Atom Protocol, PUT is constrained to mean replace. In Protocol XYZ,
> PUT is constrained to mean create. Both protocols use HTTP, both
> protocols are RESTful, but PUT has different semantics within each
> application boundary. PUT cannot possibly mean the same thing for all
> URIs, since PUT means two different things.
to know which application a URI part of in order to build caches?
> We'll never get DELETE to mean the same thing everywhere, even withinWhy then does HTTP even try to define the meanings of methods?
> the HTTP protocol (see again the WebDAV definition of DELETE compared
> to the Atom Protocol definition of DELETE). The best we can do is
> agree that it has a generic-interface meaning, and design our APIs
> accordingly, regardless of what the RFCs involved allow.
> The only method which fits your criteria, that it must unambiguously
> mean the same thing for all URIs everywhere, is GET.
DELETE means what it says in RFC 2616 (or whatever the HTTP wg comes
up with next). That is all that it means - on the web. What it means
in your application is up to you - as long as it extends the meaning
of what is in RFC 2616.
But you cannot insist that people ‘choose’ one or the other *more*
specific semantics of DELETE in their ‘application’ and stick to it.
All that is needed to be part of the web - and to be RESTful! - is to
stick to the semantics of DELETE as defined in RFC 2616.
- Eric -
Here is how I see it. I think (hope) others also see it this way.
The web defines the architecture of a global hypertext system. [*]
The web is defined by a number of RFCs (HTTP 1/1, URI generic syntax,
etc.) and other specs.
Roy Fielding’s dissertation defines an architectural style, REST.
(Here I get hazy because I have not studied this sort of thing
The web, as defined in these RFCs, (generally) conforms to the
constraints laid out in Roy Fielding’s dissertation.
In other words:
REST (architectural style)
> the web (architecture)REST defines the general constraints that the web conforms to. The web
> your web app (the implementation)
defines the way things actually get done.
For instance, REST says you should have a uniform interface. The web
defines a uniform interface.
If you accept this model of the web, and I do, the things that you are
saying about DELETE don’t make much sense.
* These statements are general; there are certainly problematic edge
cases where HTTP does not, in fact, align with the REST style.