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."
> 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.
> 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.
>
> Is my approach with separating /map and /upload wrong? Things would be
> much easier when attaching the upload functionality also to /map. Then
> it would be rather natural to go back to /map. But this approach lacks
> modularity. But I may be looking at it the wrong way.
>
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.
In each case if an error occurs the a 400 response can be returned with
error information in the page and *links* back to where they started
before the error occurred and information on how to resolve the error.
Paul.
[1]
http://greenbytes.de/tech/webdav/rfc2616.html#status.400
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109