On Jul 17, 2009, at 11:15 AM, António Mota wrote:
> Remember that you can use user-specific codes "extending" the
> "normal" ones, like
>
> 500.1 - Not on Fridays
> 500.2 - Give me a break
>
To be clear the above do not conform to status code in the status line
of an HTTP response:
http://greenbytes.de/tech/webdav/rfc2616.html#status-line
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
...
The Status-Code element is a 3-digit integer...
Status-Code = ...
extension-code
extension-code = 3DIGIT
Paul.
> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>