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. 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/
-----------------------------------