users@jersey.java.net

Re: [Jersey] Jersey's (experimental) approach to support hypermedia constraint

From: <FSauer_at_dsthealthsolutions.com>
Date: Wed, 10 Feb 2010 15:10:08 -0600

Fascinating thread! I too am struggling with the absence of content
negotiation from this thread. Accept and Content-Type headers exist for a
reason.

> 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

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.