Re: PUT and DELETE methods in 200 code

On 05.04.2011 16:38, Cameron Heavon-Jones 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.

Yes. But that service needs to understand what the intent of the client was.

If the service *only* deals with browser-initiated requests, it can be 
optimized for those.

If it also deals with other clients (think a combined 
browser/feedreader/WebDAV service), it'll have to figure out what the 
client's expectation is.

> 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.

Not sure I understand.

When the browser does a GET on the authorable resource, do you want to 
return a simple representation, or a form that allows *editing* that 
representation?

> 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.

They might be cacheable.

> 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.

Yes, but that seems to be an orthogonal issue.

Best regards, Julian

Received on Tuesday, 5 April 2011 15:04:30 UTC