On 3/30/11 10:02 AM, "Cameron Heavon-Jones" <[email protected]> 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" <[email protected]> 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). >> >> >
