Best practices for error handling between client <-> server

[Jason Dillon <ja...@planet57.com>]

I'm trying to implement a fairly generic way to handle errors when then occur on the server-side, and then have a uniform way to display some-sort of context on the client.  Is there any best practices that you folks know of in relation?

All I can think of is that I have to create a top-level response object, which can contain error information or the real entity/payload that I care about.  Or perhaps I can just have an error entity that only gets pushed back when an error occurs and have the client check for it before it tries to pull out the desired entity?  Something like that... I dunno, so if you guys know of a better way to handle this I would be very helpful.

Would have liked to see some examples of this in the distribution too.  IMO, the current examples don't provide enough client <-> server details... lots of atom/rss-ish stuff, which I personally don't care about atm.

Overall, I'm trying to get enough insight so that I can write an enunciate module to generate a java client to interact with server resources... as the client-code to request muck is highly boilerplate-ish.

Any insight would be very helpful... and some richer wink-examples/** would be even better, but I'd settle for either ;-)

--jason

Re: Best practices for error handling between client <-> server

[Jason Dillon <ja...@planet57.com>]

Yes, makes sense :-)

--jason


On Apr 4, 2010, at 6:43 PM, Mike Rheinheimer wrote:

> Hi Jason,
> 
> In my opinion, there are no "best practices", only "practices".  :)
> But seriously, the patterns used by a particular server-client REST
> model will be geared toward the needs of the application or industry
> in which it's employed.
> 
> I think the lack of examples is partly intentional, in that we don't
> want to influence JAX-RS application developers in a way that does not
> necessarily make sense for them.  However, your request is a good one.
> I personally learn best by examples.  If we would have ExampleError1,
> ExampleError2, for possible suggested patterns, that might be useful.
> Probably better to have too many examples than to deprive the
> community.  We'll have to fill out that Wink module better as we go.
> 
> As for your particular request, the only specific, concrete advice I
> would give you is to make proper use of the HTTP response codes.  You
> would, as you suggest, want to make a top-level response object, mark
> it with 500 (internal server error, or whatever is appropriate for the
> error being reported), and send back data that is in a format known to
> the client, so it can parse it and do with it what is most useful for
> your application.  The client then can use the HTTP response code to
> determine high-level flow (ProcessResponse vs. ProcessError, or again
> whatever is appropriate for the HTTP response code), then you don't
> have to parse or inspect the response entity to know what kind of
> response you're dealing with.
> 
> Make sense?
> 
> mike
> 
> 
> 
> 
> On Sun, Apr 4, 2010 at 7:35 PM, Jason Dillon <ja...@planet57.com> wrote:
>> I'm trying to implement a fairly generic way to handle errors when then occur on the server-side, and then have a uniform way to display some-sort of context on the client.  Is there any best practices that you folks know of in relation?
>> 
>> All I can think of is that I have to create a top-level response object, which can contain error information or the real entity/payload that I care about.  Or perhaps I can just have an error entity that only gets pushed back when an error occurs and have the client check for it before it tries to pull out the desired entity?  Something like that... I dunno, so if you guys know of a better way to handle this I would be very helpful.
>> 
>> Would have liked to see some examples of this in the distribution too.  IMO, the current examples don't provide enough client <-> server details... lots of atom/rss-ish stuff, which I personally don't care about atm.
>> 
>> Overall, I'm trying to get enough insight so that I can write an enunciate module to generate a java client to interact with server resources... as the client-code to request muck is highly boilerplate-ish.
>> 
>> Any insight would be very helpful... and some richer wink-examples/** would be even better, but I'd settle for either ;-)
>> 
>> --jason

Re: Best practices for error handling between client <-> server

[Mike Rheinheimer <ro...@ohmyhead.com>]

Hi Jason,

In my opinion, there are no "best practices", only "practices".  :)
But seriously, the patterns used by a particular server-client REST
model will be geared toward the needs of the application or industry
in which it's employed.

I think the lack of examples is partly intentional, in that we don't
want to influence JAX-RS application developers in a way that does not
necessarily make sense for them.  However, your request is a good one.
 I personally learn best by examples.  If we would have ExampleError1,
ExampleError2, for possible suggested patterns, that might be useful.
Probably better to have too many examples than to deprive the
community.  We'll have to fill out that Wink module better as we go.

As for your particular request, the only specific, concrete advice I
would give you is to make proper use of the HTTP response codes.  You
would, as you suggest, want to make a top-level response object, mark
it with 500 (internal server error, or whatever is appropriate for the
error being reported), and send back data that is in a format known to
the client, so it can parse it and do with it what is most useful for
your application.  The client then can use the HTTP response code to
determine high-level flow (ProcessResponse vs. ProcessError, or again
whatever is appropriate for the HTTP response code), then you don't
have to parse or inspect the response entity to know what kind of
response you're dealing with.

Make sense?

mike




On Sun, Apr 4, 2010 at 7:35 PM, Jason Dillon <ja...@planet57.com> wrote:
> I'm trying to implement a fairly generic way to handle errors when then occur on the server-side, and then have a uniform way to display some-sort of context on the client.  Is there any best practices that you folks know of in relation?
>
> All I can think of is that I have to create a top-level response object, which can contain error information or the real entity/payload that I care about.  Or perhaps I can just have an error entity that only gets pushed back when an error occurs and have the client check for it before it tries to pull out the desired entity?  Something like that... I dunno, so if you guys know of a better way to handle this I would be very helpful.
>
> Would have liked to see some examples of this in the distribution too.  IMO, the current examples don't provide enough client <-> server details... lots of atom/rss-ish stuff, which I personally don't care about atm.
>
> Overall, I'm trying to get enough insight so that I can write an enunciate module to generate a java client to interact with server resources... as the client-code to request muck is highly boilerplate-ish.
>
> Any insight would be very helpful... and some richer wink-examples/** would be even better, but I'd settle for either ;-)
>
> --jason