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
>