Re: Question about error handling in REST

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Question about error handling in REST

Paul Sandoz
Administrator


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?
>
> Ideally I would like to just call the resource method to create the main
> resource while providing some error information to render. But how would
> I instruct the browser that what it is getting is no longer the upload
> resource, but the main page. I tried setting the location header, but at
> least firefox 2 ignores this and keeps showing the upload-URL it
> originally requested.
>
> If, instead, I send a redirect to the browser, how should I preserve the
>  error information to be picked up by the redirected resource?
>

I am not sure that having the error information associated with the
resource state is a good idea. As the state of that resource requires
updating with error information specific to a previous request. I guess
it depends if you want to log the errors as state that can be exposed as
resources.

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.

Paul.


> Thanks,
> Harald.
>

--
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about error handling in REST

Harald Kirsch


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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about error handling in REST

Paul Sandoz
Administrator
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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about error handling in REST

Harald Kirsch


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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about error handling in REST

Paul Sandoz
Administrator
Harald Kirsch wrote:

>>> 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.

The browser is a "user agent" making requests, on behalf of the user,
with information supplied by the user.

I missed some more information:

   "10.4 Client Error 4xx

   The 4xx class of status code is intended for cases in which the client
   seems to have erred. Except when responding to a HEAD request, the
   server SHOULD include an entity containing an explanation of the error
   situation, and whether it is a temporary or permanent condition. These
   status codes are applicable to any request method. User agents SHOULD
   display any included entity to the user."


> 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.
>

Yes. 400 signifies that the client request is not processable by the
application.  It is up to the application to inform the client in a
response why that is. It is up to the "user agent" to render that
response appropriately.


> 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.
>

Why?


>>
>>> 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:-)
>

I bet you have been to pages that say "page not found", if so look at
the status code of the response.

Paul.

--
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]