Thanks for the responses.
I have opted to keep the 404 and add application readable codes in the header. That way the headers can be read fine grained understanding. It still doesn't please me that on both the server and client side exception handling is needed to process what essentially is a null. I will go back and look at the suggested ResourceFilterFactory later.
Using a 410 is a good idea but I do not think I can truly respect the contract. The "Permanence" requirements do not really apply to what I am doing.
florian
From: Paul Sandoz [mailto:Paul.Sandoz_at_oracle.com]
Sent: Friday, January 21, 2011 11:43 AM
To: Marek Potociar
Cc: Florian Hehlen; 'users_at_jersey.java.net'
Subject: Re: [Jersey] Re: handling nulls
On Jan 21, 2011, at 10:36 AM, Marek Potociar wrote:
How about returning 410 (GONE)[1] instead of generic 404 to distinguish functional vs. technical "not found"s?
Note that this is "expected to be considered permanent":
"The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise."
If this is not a permanent condition a 404 is correct. You could additionally send some entity body further describing the condition. Also note that if the server is down then a 404 should not be returned, a 503 should be returned, although perhaps you have no control over that aspect.
To support a null value returning a 410/404 response you might be able to use a ResourceFilterFactory that adds a container response filter checking for a null entity value. The filter could throw an exception or modify the status directly. That way you can factor out reproducing behavior to the filter. Then you need to decide when to apply the filter e.g. an annotation on the resource class perhaps, or perhaps derived from looking at the return type etc.
Also what version of Jersey are you using, i cannot recall if we changed things so that null would result in a 204.
Using a different status code is useful because it signals to clients that a different action should be taken.
Paul.
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.
________________________________
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.