On Jul 17, 2009, at 12:05 PM, António Mota wrote:
> I don't think you're right on this one.
You are not stating how you encode the sub-status code. I was stating
that if one encodes as literally given it will not conform to the
Status-Code definition as specified by HTTP 1.1
> 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
>
The Reason-Phrase is being used to convey additional sub-status code
information to the client contrary to what the HTTP specification
states:
The Status-Code is intended for use by automata and the Reason-
Phrase is intended for the human user. The
client is not required to examine or display the Reason-Phrase.
IMHO i think it is better to declare an sub-status code as an HTTP
response header.
Some APIs make it hard to consistently set or get the Reason-Phrase.
For example, it is not possible in Servlet to set the Reason-Phrase
and a response entity. IIUC it is not possible to retrieve it from
HttpURLConnection.
Paul.
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>