Remember that you can use user-specific codes "extending" the "normal"
ones, like
500.1 - Not on Fridays
500.2 - Give me a break
That way you can treat them on your own clients using your used-specific
codes, and all other clients simply ignore the "extensions" and behave
accordingly the "main" code.
Ricardo Borillo wrote:
> Hi Paul,
>
> Thanks for the clarifications :)
>
> ---
> Salut,
> ====================================
> Ricardo Borillo Domenech
> http://xml-utils.com
>
>
>
> On Fri, Jul 17, 2009 at 09:47, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
>
>> On Jul 17, 2009, at 7:50 AM, Ricardo Borillo wrote:
>>
>>
>>> Hi,
>>>
>>> When i start designing server side, i review some well known REST APIs
>>> implementations like Flickr or Twitter.
>>>
>>> In Flickr API, an HTTP 200 error code is always returned:
>>>
>>> http://www.flickr.com/services/api/flickr.photos.getInfo.html
>>>
>>>
>> That is bad design. Often the reason for such a design is the implementation
>> of the API is RPC-based.
>>
>> For example in the following the:
>>
>> http://www.flickr.com/services/api/request.rest.html
>>
>> To request the flickr.test.echo service, invoke like this:
>>
>> http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value
>>
>> The use of the query parameter "method" is a big give away that this is not
>> RESTful. Essentially HTTP is being used as transport protocol and not an
>> application protocol.
>>
>>
>>
>>> My question is only about of what are the best practices for handle
>>> normal responses and user defined exceptions in the client, using
>>> Jersey and JAXB :)
>>>
>>> Returning an HTTP 500 error code with the error information in the
>>> messagebody, works perfect with the client API. But, This is the
>>> proper way to implement it?
>>>
>>>
>> Yes. If there is an error with the server side processing the client
>> request, because it is incorrect, then a 400 status code should be used. If
>> there is an error on the server side because it could not produce a response
>> then a 500 status code should be used. If you require additional error
>> information it can be sent in the response entity.
>>
>> The client API will thrown a UniformInterfaceException for status codes >=
>> 300 for Java types other than ClientResponse.
>>
>> Paul.
>>
>>
>>> Thanks for your help
>>>
>>> ---
>>> Salut,
>>> ====================================
>>> Ricardo Borillo Domenech
>>> http://xml-utils.com
>>>
>>>
>>>
>>> On Thu, Jul 16, 2009 at 23:14, tarjei<tarjei_at_nu.no> wrote:
>>>
>>>> On 07/16/2009 09:33 PM, Craig McClanahan wrote:
>>>>
>>>>> Ricardo Borillo wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm implementing my first REST API and i'm facing some design problems
>>>>>> ...
>>>>>>
>>>>>> In my server REST service i issue, through jaxb binding, an instance
>>>>>> of a class in application/xml format.
>>>>>> If an user defined exception arises, i issue an error message (i'm
>>>>>> using an exception mapper) with an HTTP 200 error code:
>>>>>>
>>>> If you control the server side of the API, then you should try to answer
>>>> with a HTTP 500 containing the error information in the responsebody -
>>>> thus
>>>> informing the client that there is an error on the other side.
>>>>
>>>> I'm not sure how well that works with the client API , but IMHO that is a
>>>> cleaner option.
>>>>
>>>> Regards,
>>>> Tarjei
>>>>
>>>>>> <error code="1" />
>>>>>>
>>>>>> This error message is built with JAXB too.
>>>>>>
>>>>>> The question is how to manage this situation in the client. If i have:
>>>>>>
>>>>>> ClientResponse response = webResource.path("test/x").accept(
>>>>>> MediaType.APPLICATION_XML).get(ClientResponse.class);
>>>>>>
>>>>>> if (response.getStatus() == 200)
>>>>>> {
>>>>>> return response.getEntity(MyJAXBEntity.class);
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> throw new Exception(response.getStatus());
>>>>>> }
>>>>>>
>>>>>> How can i know that i'm getting an error xml or other message using
>>>>>> JAXB binding?
>>>>>> How can i design this type of interaction?
>>>>>>
>>>>>> Thanks a lot and sorry if this is an obvious question :)
>>>>>>
>>>>>>
>>>>> Would something like this work?
>>>>>
>>>>> ClientResponse response = webResource.path("test/x").accept(
>>>>> MediaType.APPLICATION_XML).get(ClientResponse.class);
>>>>>
>>>>> if (response.getStatus() == 200)
>>>>> {
>>>>> return response.getEntity(MyJAXBEntity.class);
>>>>> }
>>>>> else
>>>>> {
>>>>> err = response.getEntity(MyErrorMessage.class);
>>>>> throw new Exception(err.getCode());
>>>>> }
>>>>>
>>>>>
>>>>> where the MyErrorMessage class has a "code" property containing a string
>>>>> representation of the "code" value.
>>>>>
>>>>> Craig
>>>>>
>>>>>
>>>>>> ---
>>>>>> Salut,
>>>>>> ====================================
>>>>>> Ricardo Borillo Domenech
>>>>>> http://xml-utils.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>>
>>>> --
>>>> Tarjei Huse
>>>> Mobil: 920 63 413
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>