users@jersey.java.net

[Jersey] Re: handling nulls

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 21 Jan 2011 10:36:57 +0100

How about returning 410 (GONE)[1] instead of generic 404 to
distinguish functional vs. technical "not found"s?

Marek

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11

On 21.1.2011, at 9:20, Florian Hehlen wrote:

> Hi,
>
> I have a problem with how nulls are being handled by jersey and
> jaxb. I have a number of end-points in my web-service that can
> return null if no result is found for the request. At the moment
> this results in some JAXB exception and then jersey converts it to
> an HTTP 500 status.
>
> The only way I have found to handle this situation is to throw an
> EntityNotFoundException. This was ok, although not great, as long as
> I returned a HTTP 404 status. This started getting more complicated
> as recently we have wanted to make sure we can differentiate, from
> the client side, between functional and technical 404’s.
>
> So three options present themselves.
> 1. Add some kind of header tag to 404s that are the result of
> the application completing the call but finding nothing to return.
> This makes it possible to distinguish if nothing was found because
> server is down or if provided ID does not exist.
> 2. Return some other http status that we will know is to be
> mapped to entity not found.
> 3. Return something that is semantically correct. With
> collections I can return an empty list (<MyEntities/>) without
> problems so I should be able to return <MyEntity/>. It is valid XML
> and the Jersey client does convert that to a null.
>
> Choice 1 is interesting but requires sophisticated error handling by
> the client for something that is not, after all, an error or an
> exception.
>
> Choice 2 breaks REST and general web conventions by overloading the
> meaning of existing http status. The best type I have found in the
> list of specified types is 204 – NO CONTENT. But when I read about
> intended purpose it fails to represent my use-case.
>
> Choice 3 is ideal because it fits my API requirements and seems
> elegant and semantically correct. But the only way I have found to
> implement it is a bit strange. It relies on using exception handling.
>
> I do the following:
> · Implemented NotFoundException and ExceptionMapper approach
> as stated in section 2.8 of the user guide(http://jersey.java.net/nonav/documentation/latest/jax-rs.html#d4e418
> )
> · Rather than return a 404 exception I return a 200 status
> with an empty tag <MyEntity>
>
> I have a few issues with this approach:
> · In my view exception handling should not be used for
> implementing functionality.
> · It doesn’t scale very well
> o I have to add code for each entity type I want to handle
> o I have not figured out how I could create a response based on
> the wanted mime-type(xml, json, fastinfoset,etc)
> · I could write my own message body writers but then I would
> lose that perfectly fine support I am getting from JAXB.
>
> Is there something I am missing? Is there a better way to address
> this issue?
>
>
> Cheers,
> Florian
>
>
> The information in this e-mail is intended only for the person or
> entity to which it is addressed.
>
> It may contain confidential and /or privileged material. If someone
> other than the intended recipient should receive this e-mail, he /
> she shall not be entitled to read, disseminate, disclose or
> duplicate it.
>
> If you receive this e-mail unintentionally, please inform us
> immediately by "reply" and then delete it from your system. Although
> this information has been compiled with great care, neither IMC
> Financial Markets & Asset Management nor any of its related entities
> shall accept any responsibility for any errors, omissions or other
> inaccuracies in this information or for the consequences thereof,
> nor shall it be bound in any way by the contents of this e-mail or
> its attachments. In the event of incomplete or incorrect
> transmission, please return the e-mail to the sender and permanently
> delete this message and any attachments.
>
> Messages and attachments are scanned for all known viruses. Always
> scan attachments before opening them.