Re: PUT and DELETE methods in 200 code

On 04/04/2011, at 6:57 PM, Julian Reschke wrote:

> On 04.04.2011 19:49, Cameron Heavon-Jones wrote:
>> ...
>> Doesn't this leave the default behaviour of services to be browser-sniffing again? If no decision can be made based on Accept, there is no other information from which to deduce the content to produce, if any. That a user requires the information is only deducible by the UA.
> 
> Well, we should do better than browser sniffing.
> 

Indubitably :)


>> The alternative is to mandate that content is provided for all responses (even if that content is empty), and for the server to pick the most relevant format by means of Accept.
> 
> The hard part is not whether or not to send content, but *what* to send. Some clients may want a new representation of the resource (PUT->200), some will not.
> 
>> ...
> 
> BR, Julian


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>

The verboseness or brevity of the responses can be defined by the service and on a format-by-format basis.

For "Accept: ", ie undefined, the service may default to the most appropriate format, probably text/plain, or maybe even a 204. There is nothing stopping services from returning different status codes for different requests.

I think i'm starting to take the view that this may even be out of scope for forms, should the responsibility of forms not be to provide the interface for a user to tailor a http request? As long as the request is valid, the form has fulfilled its role and after that point it is the UA's responsibility to handle the response to that request in conformance with http. 

The response handling from form submissions could be included in html but more as recommended guidelines than specification. The http spec has already defined the behaviour has it not?

cam

Received on Tuesday, 5 April 2011 13:55:37 UTC