W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: PUT and DELETE methods in 200 code

From: mike amundsen <mamund@yahoo.com>
Date: Tue, 5 Apr 2011 10:53:54 -0400
Message-ID: <BANLkTin_=B7HDvAZ91s2dt0Rg24PtZUCOA@mail.gmail.com>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, public-html@w3.org
cam:

>From HTTP 2616 (this does not change for HTTPbis, either):

"Responses to this method [POST] are not cacheable, unless the
response includes appropriate Cache-Control or Expires header
fields."[1]
"Responses to this method [UT] are not cacheable."[2]
"Responses to this method [DELETE] are not cacheable."[3]

Note that responses to POST _are_ cacheable. Also, HTTPbis sez: "Note
that POST caching is not widely implemented."[4]

Since we're talking primarily about PUT/DELETE here, this might not be
too big a deal, I guess.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7
[4] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.5

On Tue, Apr 5, 2011 at 10:38, Cameron Heavon-Jones <cmhjones@gmail.com> wrote:
>
> On 05/04/2011, at 3:14 PM, Julian Reschke wrote:
>
>> On 05.04.2011 15:55, Cameron Heavon-Jones wrote:
>>> ...
>>> Ok, so the Accept header can only be used to define the format of the response.
>>>
>>> But isn't it the server's responsibility to define the content for each format? Why can a server not have the following mapping?
>>>
>>> PUT /user/123
>>>
>>> Accept: text/plain ->  "User created"
>>> Accept: application/xml ->  <xml><user id="123"/></xml>
>>> Accept: application/json ->  {id:123}
>>> Accept: text/html ->  <html>...</html>
>>> ...
>>
>> Yes. But what do you return in the case of text/html? A status message? An HTML representation of the resource? An HTML representation of a form that can *edit* the resource?
>>
>> The media type just doesn't tell you that.
>>
>> Best regards, Julian
>
>
> The content of text/html should be defined by the implementation of the service.
>
> I think a distinction must be made between the response of a GET on the resource to the response of a PUT or DELETE (or even POST) to a resource.
>
> Since responses to PUT and DELETE (and POST) are all non-cachable, they do not represent the same result as doing a GET on the same resource, and will not conflict with the response from GET.
>
> That the service is allowed to provide a custom html representation in response to PUT or DELETE is a feature and benefit. It allows the response to be unique to the request and include specific data such as the form field values, error messages or even additional contextual links to various other resources which may aid the user in preparing a valid request, if the request was in error.
>
> cam
>
>
>
>
Received on Tuesday, 5 April 2011 14:54:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC