On Jul 17, 2009, at 2:07 PM, António Mota wrote:
> 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?
Yes, cause that is not specified to be machine processable.
> 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.
>
Right, although one should be careful to not intersect with other
standardized codes say specified by WebDAV. Of course the problem here
is the status code are not very extensible. Which is why an HTTP
response header might be most appropriate.
Paul.
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>