Am 22.07.2008 17:38 schrieb Paul Sandoz:
>
>
> Harald Kirsch wrote:
>> Hello,
>>
>> can anyone shed some light on best practices for handling errors when
>> creating a resource.
>>
>> My application provides for the upload of some data which results in the
>> creation of a new resource. If the uploaded data is malformed, I want to
>> display the main application page, but with an additional error message.
>> How is this normally implemented?
>>
...
>>
>> If, instead, I send a redirect to the browser, how should I preserve the
>> error information to be picked up by the redirected resource?
>>
...
> 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. 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.
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.
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.
Ideas?
Harald.
--
--------------+---------------------------------------------
Harald Kirsch | pifpafpuf bei gmx punkt de