Am 23.07.2008 10:34 schrieb Paul Sandoz:
> Harald Kirsch wrote:
>>> Alternatively an error processing a POST/PUT request could result in a
>>> response with an error status code 400 (Bad Request) in the response
>>> with the error information in HTML of what went wrong. In JAX-RS you
>>> would throw an exception and map that exception to a response or
>>> directly throw a WebApplicationException. Links in that HTML could take
>>> the user to the main page or to retry the upload.
>>
>> Naah.
>
> Yeeeess :-)
>
>
>> It is not a 400. There was not a technical problem between
>> machines involved. It is just a user mistake and the machines must and
>> will deal with this gracefully.
>>
>
> 400 is a *client error* [1]. From the HTTP spec:
>
> "The 4xx class of status code is intended for cases in which the
> client seems to have erred"
>
> "10.4.1 400 Bad Request
>
> The request could not be understood by the server due to malformed
> syntax. The client SHOULD NOT repeat the request without
> modifications."
This is all nice and well, but the *client* mentioned in this spec is a
piece of software, like a browser that is not properly implemented or
not properly communicating on the technical level for whatever reason.
If the user interface provides functionality to the human in front of
the machine to upload an XML file and the human errs and uploads a PNG
image of his grandma, then this is certainly not a 400 (even if tech
guys like us would call it even worse). It is much the same case as
entering the zip-code into the street-field of some e-commerce
application. You are not seriously suggesting to send a 400 in this case.
And of course I don't want to validate the XML on the client side. Maybe
I should not have called it an 'error' in the subject header, but rather
a 'user mistake' or whatever?
>
>> To first send the user to an intermediate page with an error message is
>> not what user expect today. The resulting page has to have the complete
>> functionality of where they started plus potentially additional help to
>> correct their mistake.
>>
>
> The page can still do that by providing links accordingly to what you
> require.
That would mean to provide nearly identical functionality from two
different resources.
>
>
>> Say, the main resource is called /map. When uploading some data, this
>> addresses resource /upload. This resource creates a new resource with
>> the user's data with some new name, /map/bladfasl, if all goes well and
>> redirects to /map/bladfasl. But if the data provided by the user is not
>> all good, the user should
>>
>> a) end up on /map again,
>> b) get an informational message there about what went wrong.
>>
>> Obviously just a redirect to /map does not cut it. The /map resource
>> needs to know somehow that something went wrong.
> Why not allow the client to POST to /map? or allow the client to PUT to
> /map/{file}? for the former the server is in control of the URI space of
> the newly created resource, for the latter the client is in control.
Yes, the longer I think about it, it seems that POST to /map is the
cleanest approach, even if it requires even more functionality on that
single resource. It would ease the error handling a lot, except that, as
mentioned above, I don't agree to return a 400. Users will not want to
see such a technicality. (Have to check, what the browser does with a
400. Maybe it surprises me with some magic:-)
Cheers,
Harald.
--
--------------+---------------------------------------------
Harald Kirsch | pifpafpuf bei gmx punkt de