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

Re: Methods and the uniform interface [was: Re: [rest-discuss] REST isn't hard to learn, it's just taught wrong.

Expand Messages
  • Roy T. Fielding
    ... Yes. BTW, Allow: DELETE in HTTP is a form of hypertext, as are all of the resource metadata fields (data-embedded control information). That is why they
    Message 1 of 37 , Dec 29, 2009
    View Source
    • 0 Attachment
      On Dec 29, 2009, at 1:56 PM, Eric J. Bowman wrote:

      > No, the presence of DELETE in an Allow: header informs the client that
      > a DELETE is possible, but that is all.
      >
      > A self-documenting, hypertext-driven REST API may instruct the client
      > to do a HEAD request on each URL appearing in a <form> listing
      > deletable resources, and further instruct the client that it must
      > perform a conditional DELETE (to avoid deleting a resource that someone
      > else just altered, always consider time and multi-user). If the Allow:
      > header is implemented, the hypertext may instruct the client to exclude
      > any resource from the deletable collection that didn't explicitly
      > Allow: DELETE when the HEAD request was made.
      >
      > Yes, DELETE results in success or failure, however it's up to DELETE's
      > implementation for a given resource to determine the failure mode...
      > perhaps 401 to initiate challenge-response. Informing the user as to
      > why the DELETE failed differentiates the uniform REST interface from
      > the generic HTTP interface. Calling the DELETE method of a resource
      > out-of-band of the hypertext application may even have caused the
      > failure, as we shall see...
      >
      > (I haven't checked RFC 2616bis lately, but AFAIK the Allow: header may
      > be sent with GET and HEAD requests, not just as part of a 405 response.)

      Yes.

      BTW, "Allow: DELETE" in HTTP is a form of hypertext, as are all of
      the resource metadata fields (data-embedded control information).
      That is why they were considered part of the representation, though
      I think we are making Allow just a response-header in httpbis.

      ....Roy
    • Subbu Allamaraju
      ... Headers that drive conditional requests are in deed part of a representation, and media types such as application/atom+xml, text/html do not have to
      Message 37 of 37 , Dec 30, 2009
      View Source
      • 0 Attachment
        On Dec 30, 2009, at 5:49 AM, Eric J. Bowman wrote:

        > Conditional requests are part of HTTP's generic interface. There are
        > two ways to make conditional requests part of a uniform REST interface.
        > First, is if the media type specifies conditional requests (Atom).
        > Second, is if the conditional request is API-specific, and that API is
        > self-documenting in hypertext.
        >
        > A conditional DELETE isn't described by any media type, i.e. there's no
        > common out-of-band knowledge detailing this application behavior. So in
        > order for a conditional-DELETE API to be RESTful, hypertext must exist
        > which instructs clients of this requirement in-band. Xforms makes it
        > possible (not saying it's easy) to specify the round-trip of an Etag in
        > an If-Match header be sent with DELETE, in hypertext.
        >
        > Without the server explicitly describing this interface in hypertext,
        > how is a client to determine that DELETE must be a conditional request
        > on the system? Besides out-of-band knowledge hard-coded into the
        > client...

        Headers that drive conditional requests are in deed part of a representation, and media types such as application/atom+xml, text/html do not have to specify their behavior. Neither Atom nor AtomPub specify conditional requests (they just use them in examples). No per media type specification or out of band knowledge is necessary. In fact, per media type specification of such behavior would break caches.

        Subbu
      Your message has been successfully submitted and would be delivered to recipients shortly.