I don't think you're right on this one. That extension-code you refer
are the codes like, for example, the ones from WebDAV, like
102 Processing
423 Locked
not the HTTP substatus, like in IIS
http://blog.crowe.co.nz/archive/2005/08/26/231.aspx
So, using my own codes I can say "C'mon man, [500.2], [500.1]"...
:)
Paul Sandoz wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>