Re: PUT and DELETE methods in 200 code

On 05/04/2011, at 4:03 PM, Julian Reschke wrote:

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

Do you foresee a scenario where the same request is submitted yet a different response is required? This would be impossible for any service and against the authority of the service to define it's own implementation.

In the example of a combined agent (i'm thinking in the same vein of the old netscape navigator?) wouldn't the different functional contexts define different requests?

Why would a WebDAV service initiate a request with "Accept: text/html" if it doesn't want html?

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

The representation should be whatever the resource defines... if i had an authorable resource i would probably be inclined to return a simple representation for the base and maybe provide a link to an editable representation, eg:

http://www.example.com/user/123

http://www.example.com/user/123?edit=true

or maybe

http://www.example.com/user/123/profileEditor


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

True, true :)

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


Yes, it isn't really relevant but there would seem to be nothing stopping this from being implemented in such a way today, even if only for POST.

Cam

Received on Tuesday, 5 April 2011 15:39:18 UTC