Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] An approach to deleting multiple resources use one DELETE

Expand Messages
  • Erik Hetzner
    At Mon, 6 Apr 2009 15:29:32 -0600, ... If you don’t think so, then you don’t think that your application is part of the web. Of course when designing a web
    Message 1 of 112 , Apr 6, 2009
    • 0 Attachment
      At Mon, 6 Apr 2009 15:29:32 -0600,
      Eric J. Bowman wrote:
      >
      > 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.

      If you don’t think so, then you don’t think that your application is
      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,
      no less.

      > > There are no application boundaries in terms of method semantics.
      > > 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.

      So you are saying you do not believe in a uniform interface? We need
      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 within
      > 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.

      Why then does HTTP even try to define the meanings of methods?

      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.

      best,
      Erik Hetzner
    • Erik Hetzner
      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
      Message 112 of 112 , Apr 6, 2009
      • 0 Attachment
        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
        deeply).

        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)
        > your web app (the implementation)

        REST defines the general constraints that the web conforms to. The web
        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.

        best,
        Erik Hetzner

        * These statements are general; there are certainly problematic edge
        cases where HTTP does not, in fact, align with the REST style.
      Your message has been successfully submitted and would be delivered to recipients shortly.