On Feb 10, 2010, at 9:55 PM, Jan Algermissen wrote:
>
> On Feb 10, 2010, at 9:21 PM, Paul Sandoz wrote:
>
>>
>> On Feb 10, 2010, at 8:38 PM, Jan Algermissen wrote:
>>
>>
>>> What I am talking about is that the server cannot be constrained
>>> to send a particular media type (let alone Link headers). It might
>>> send application/order+xml for two years and the next day start to
>>> send an HTML representation of the order. Client side APIs should
>>> IMHO emphasize this and enforce proper client side implementation
>>> instead of leading client developers to think they can make any
>>> kind of assumption whatsoever.
>>>
>>
>> So what you are saying is the client needs to declare to the server
>> what it accepts and if it does not get an appropriate acceptable
>> response then it is an error condition?
>
> NO! A 406 Not acceptable is just another state in the application
> the client has to deal with.
I agree, but it is an HTTP *client error* response. All i am
suggesting is such response handling can, in a client API design, can
be dealt with using Java exceptions.
Paul.
> Any 4xx does not mean that the contract is broken (the contract is
> HTTP), only that there was a condition that the client needs to deal
> with.
>
> Its radical, but this is the consequence of the client/server
> decoupling that REST style architectures provide. It is important to
> emphazise that, because if you write clients that rely on any kind
> of expectation about the representations they'll receive might break
> when the server evolves.
>
> I like to view it that way: If I am a service owner and plan to
> change the service implementation there is no need whatsoever to
> know about the clients that consume my service. I can change the
> service as I like as long as I do not change the semantics of
> existing resources.
>
> Jan
>
> P.S. As radical as this might sound at first the consequences are
> actually far less dramatic but I do not want to clutter up this
> thread with those issues.
>
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> -----------------------------------
> Jan Algermissen, Consultant
> NORD Software Consulting
>
> Mail: algermissen_at_acm.org
> Blog: http://www.nordsc.com/blog/
> Work: http://www.nordsc.com/
> -----------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>