Re: PUT and DELETE methods in form@method

I'm struggling to see what the problem with forms using other HTTP methods is....

On 30/03/2011, at 3:13 PM, Simpson, Grant Leyton wrote:

> 
> 
> 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:59:22 UTC