So what you're saying is that the use by Microsoft of substatus doesn't
conform to the specification because it uses part of the reason-phrase
to send the sub-code? Gee, I never that Microsoft could do such thing...
Ok, so instead of using
500.1 - Not on Fridays
500.2 - Give me a break
you could use
511 - Not on Fridays
512 - Give me a break
That way you're using a extension-code that is conform with the
specification, your own clients understand it, and all other clients
will interpret then as 500.
Paul Sandoz wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>