Re: PUT and DELETE methods in form@method

A user agent should always respond by rendering whatever content is returned by the server as specified by the Accept header. This defines what response the agent can handle and what the user wants to see.

The response status is a machine code for automated agents, not user agents. To expect a user agent (browser) to handle arbitrary response states for a user removes the user from making their decisions based on the information sent back from the server. 

In the case of an automated agent, ie a business process, the response status is usually enough information with which to decide what action to take. Users require a formatted response in order to inform their decision making process.

As a scenario, if a user submits a form for processing and the form contains server-vailidation errors, how else is this to be communicated to the user other than by providing back a html response with the original form, values and errors? It would seem that a unique request dictates the need for a unique response.

Even for automated agents, the need for a customised response as a result of a failed request is desired as it is the only means of informing the agent of the specific nature of the error. Http status codes are too corse grained for anything other than highest-level automation.

cam


On 30/03/2011, at 2:29 PM, Simpson, Grant Leyton wrote:

> Right, but this does still does not cover specifying how the user agent
> should respond to a HTTP 200 and how that response integrates with a given
> application.
> 
> On 3/30/11 9:10 AM, "Dominik Tomaszuk" <ddooss@wp.pl> wrote:
> 
>> It could be supported in the same way as POST: 200 OK (describing or
>> containing the result of the action). HTTP in PUT and DELETE allowed 200
>> if an existing resource is modified in PUT or if it is a successful
>> response (and it is consistent with the approach RESTful).
> 
>

Received on Wednesday, 30 March 2011 14:03:27 UTC