On Feb 10, 2010, at 10:10 PM, FSauer_at_dsthealthsolutions.com wrote:
>
> Fascinating thread! I too am struggling with the absence of content negotiation from this thread. Accept and Content-Type headers exist for a reason.
Conneg does not help if the client relies on assumptions that the server cannot fullfil. It does not change the issue discussed.
But it definitely is related, yes.
>
> > if you write clients that rely on any kind of expectation about the representations
>
> I don't believe this is realistic. If a client states to the server that it Accepts a certain type he either gets the correct representation or an error
Yes. But if you code the client with the assumption that certain links will definitely be present in the response the client is not doing REST. Clients must react on what they are being sent (react on the state they are being put into by the server) and try to persue their goal from there.
Jan
>
> Frank
>
>
>
> Marc Hadley <Marc.Hadley_at_Sun.COM>
> Sent by: Marc.Hadley_at_Sun.COM
> 02/10/2010 03:04 PM
> Please respond to
> users_at_jersey.dev.java.net
>
> To
> users_at_jersey.dev.java.net
> cc
> Subject
> Re: [Jersey] Jersey's (experimental) approach to support hypermedia constraint
>
>
>
>
>
> On Feb 10, 2010, at 3:55 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.
> >
> I'm struggling to imagine what kind of specialized client program I could write that can't depend on *anything* from the server. Sure I could write a generic browser but how do I write a program that orders a widget without human intervention if I can't even rely on the media type I'm going to get back ?
>
> I don't think it would be cluttering this thread to discuss this as I think its fundamental to the kind of client API we could create.
>
> Marc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>
> Please consider the environment before printing this email and any attachments.
>
> This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------