Re: PUT and DELETE methods in 200 code

Apologies, my haste has brought error again. UAs do follow 303. I should complete the browser tests before i make such statements.

cam

On 05/04/2011, at 4:37 PM, Cameron Heavon-Jones wrote:

> Thanks for catching my error.
> 
> I don't think my oversight is an issue as it leaves the service in control of defining the cachability of POST responses, if appropriate.
> 
> It would seem that the recommendation to use 303 is to provide the default representation of GET, allowing agents to choose if they want to follow the redirection if they are interested in having content, or ignore it if they don't want content. Ironically it seems browsers have chosen not to follow the 303 yet automated agents probably would :)
> 
> cam
> 
> 
> On 05/04/2011, at 3:53 PM, mike amundsen wrote:
> 
>> 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 15:50:53 UTC