Re: PUT and DELETE methods in 200 code

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:39:24 UTC