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