W3C home > Mailing lists > Public > public-html-comments@w3.org > March 2011

Re: PUT and DELETE methods in form@method

From: Simpson, Grant Leyton <glsimpso@indiana.edu>
Date: Wed, 30 Mar 2011 14:13:00 +0000
To: Cameron Heavon-Jones <cmhjones@gmail.com>
CC: Dominik Tomaszuk <ddooss@wp.pl>, "T.J. Crowder" <tj@crowdersoftware.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>
Message-ID: <C9B8B264.C1A8%glsimpso@indiana.edu>


On 3/30/11 10:02 AM, "Cameron Heavon-Jones" <cmhjones@gmail.com> wrote:

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

Right. I agree and I'm not advocating that this would be the way to do it.
I was trying to point out that even were it to be done that way, that
still doesn't specify behavior at the level of the user agent's handling
the HTML form.

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

Agreed.

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

Absolutely. And that's why I don't think it's a good idea. (But I did a
poor job before of expressing that.)

>
>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:13:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:06 GMT