... 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 theyDec 29 7:40 PM 1 of 37View SourceOn Dec 29, 2009, at 1:56 PM, Eric J. Bowman wrote:
> No, the presence of DELETE in an Allow: header informs the client thatYes.
> 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.)
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.
... 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 toDec 30 7:28 AM 37 of 37View SourceOn Dec 30, 2009, at 5:49 AM, Eric J. Bowman wrote:
> Conditional requests are part of HTTP's generic interface. There areHeaders 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.
> 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