mike amundsen wrote:

>

> I'm contemplating a working definition for a "Hypermedia Client."

> Here are my first attempts:

>



OK, I'll bite.  I doubt we disagree, but I think your wording leads the

wrong direction; taken out of the context of the thesis, "the presence

of application control information" may be easily misconstrued to also

apply to javascript, when Roy meant it as linking/posting.



>

> 1 - "A Hypermedia Client supports advancing it's own application

> state based on application control information supplied in server

> responses."

>



Implies that the server controls the application state, first by using

"client" instead of "user-agent".  It's the user who chooses which

application state to transition to; one option is a return to the

previous state (back button), which isn't supplied in server responses.



>

> 2 - "A Hypermedia Client supports advancing application state by

> sending requests to servers based on application control information

> supplied in server responses."

>



User-agents are supposed to follow their noses, this sounds like servers

leading user-agents about by the nose.  What I mean is, the server can

only supply state-transition *options* (control information), not state-

transition *control* (control directives).  It violates REST to use HTML

meta-redirection.



>

> 3 - "A Hypermedia Client supports advancing application state by

> sending requests to servers based on application control information

> embedded within, or as a layer above, the presentation of information

> supplied in server responses."

>



Still doesn't account for that pesky back button; nor does it account

for state transitions derived from user input, IP address or REFERER

header.  Your wording makes it sound like the user-agent has knowledge

of what application state will result from following a given transition.



-Eric

On Oct 23, 2011, at 5:12 AM, Glenn Block wrote:



> I owuld add one exception to 1, which is the application root as there needs

to be some known uri which is the entry point of the application otherwise

you'll never access the application in the first place....



No necessarily because the client could obtain that URI from a

entry-point-by-service-type lookup (e.g. via DNS[1])



Nevertheless, I'd make clear (sort of as Glenn suggests) that clients typically

know entry URIs (maybe even many) of applications. Furthermore, I'd make

explicit that it is perfectly fine for clients to keep those entry URIs for as

long as they wish[2] (aka bookmarking) and that this puts a responsibility on

servers to maintain all entry URIs over time ("Cool URIs don't change..." [3]).



Jan





[1] http://www.infoq.com/articles/rest-discovery-dns

[2] Until they see a 40 Gone for it

[3] http://www.w3.org/Provider/Style/URI.html





>

> On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:

> Great to see you fleshing this out. In terms of prior art, Darrel has done a

bunch of work around hypermedia clients with his Rest Agent stuff.

>

> A few other thoughts

>

> 1. A hypermedia client is not coupled to the uri space of the application /

does not contain hard coded logic for uris on the server.

>

> 2. A hypermedia client ignores hypermedia controls that it cannot handle / it

does not break by the presence of new hypermedia controls.

>

> 3. A hypermedia client advances application state by choosing from available

hypermedia controls in server responses.

>

>

>

> On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:

>

>

> ** cross-posted **

>

> I'm contemplating a working definition for a "Hypermedia Client." Here are my

first attempts:

>

> 1 - "A Hypermedia Client supports advancing it's own application state based

on application control information supplied in server responses."

>

> 2 - "A Hypermedia Client supports advancing application state by sending

requests to servers based on application control information supplied in server

responses."

>

> 3 - "A Hypermedia Client supports advancing application state by sending

requests to servers based on application control information embedded within, or

as a layer above, the presentation of information supplied in server responses."

>

> The germ of this definition is loosely based on a Fielding's description of

"Distributed Hypermedia"[1]

>

> The point of this exercise is:

> 1) Is there a generally agreed definition?

> 2) Can a definition be useful in evaluating/analyzing existing

implementations? (e.g. "Is 'this' a hypermedia client?")

> 3) Can a definition be useful in creating new implementations that "meet" the

definition? (e.g. "Here is what you need to build a hypermedia client....")

>

> Any/all feedback is welcome.  Possibly there is "prior art" here of which I am

unaware; please point me to any reference material you may think useful. Maybe

you've gone through a similar process and would like to send along your

experiences.

>

> Thanks in advance.

>

> [1]

http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1_3

>

> mca

> http://amundsen.com/blog/

> http://twitter.com@mamund

> http://mamund.com/foaf.rdf#me

>

> #RESTFest 2011 - Aug 18-20

> http://restfest.org

>

>

>

>

>

>

>

On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:

> On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:

>>

>> If the link relations are dereferenceable URIs, you can use HTTP to hint

>> to clients about the freshness of the semantics (i.e. with Cache-Control,

>> ETags, etc.)

>

> Indeed. And that's a good practice. But it will only give you "hints" about

> the coupling and whether it is still "intact". It won't prevent breaking the

> coupling if you change the semantics. And it won't prevent the need to

> create a new link relation namespace if you want to enable new semantics

> while leaving the old namespace with its semantics intact.



It does prevent the need provided the changes aren't breaking.



Is that not enough?



Cheers,

Mike

On Tue, Oct 25, 2011 at 6:08 PM, Nick Gall <nick.gall@...> wrote:

> On Tue, Oct 25, 2011 at 12:54 PM, Mike Kelly <mike@...> wrote:

>>

>> On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:

>> > On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:

>> >>

>> >> If the link relations are dereferenceable URIs, you can use HTTP to

>> >> hint

>> >> to clients about the freshness of the semantics (i.e. with

>> >> Cache-Control,

>> >> ETags, etc.)

>> >

>> > Indeed. And that's a good practice. But it will only give you "hints"

>> > about

>> > the coupling and whether it is still "intact". It won't prevent breaking

>> > the

>> > coupling if you change the semantics. And it won't prevent the need to

>> > create a new link relation namespace if you want to enable new semantics

>> > while leaving the old namespace with its semantics intact.

>>

>> It does prevent the need provided the changes aren't breaking.

>>

>> Is that not enough?

>

> No. Inevitably, if the hypermedia interface is successful and evolves, some

> change WILL be breaking. That is the whole point of mnot's excellent blog

> post on the subject.



Right, the point being it gets you far enough so as there's no need to

be concerned about having to create an additional link relation for a

breaking change, as having to do so is reduced to the lowest rate

realistic/possible for a machine-consumed application.



On another note; I'm surprised nobody's preached the mystical

evolvability-inducing powers of 'forms' yet - apparently they solve

this problem. Or so we're told.. ;)



Cheers,

Mike

On Tue, Oct 25, 2011 at 7:03 PM, Will Hartung <willh@...> wrote:

>

>

> On Tue, Oct 25, 2011 at 10:29 AM, Mike Kelly <mike@...> wrote:

>>

>> Right, the point being it gets you far enough so as there's no need to

>> be concerned about having to create an additional link relation for a

>> breaking change, as having to do so is reduced to the lowest rate

>> realistic/possible for a machine-consumed application.

>>

>> On another note; I'm surprised nobody's preached the mystical

>> evolvability-inducing powers of 'forms' yet - apparently they solve

>> this problem. Or so we're told.. ;)

>

> The forms offer insight in to what the server is expecting for a particular

> operation.

>

> The interface will evolve in both directions. On the server side, in the

> number and variety of links that it publishes as the client navigates.

> Whether a client can actually recognize and support the new links is not

> really relevant. The clients (especially machine clients) will remain

> steadfast in their interpretation of the representation until a "breaking"

> event happens.

>

> This breaking event is either some underlying, foundation failure (i.e. the

> format has changed beyond recognition for the client), or its imposed

> externally upon the client by the clients controller (for example the want

> to now support some of this new functionality).

>

> Through inspection, a client can look at the resource representation and

> determine what links are supported by the server, and match that list to the

> understanding of the client, as in which of those links it knows how to

> follow based on their rels.

>

> From an input perspective, the FORM publishes the information that the

> server wants to know. The process for the client is the same. The client

> will have to evolve in order to handle any new form fields just like it

> would have to evolve to handle any new links that it discovers.  But the

> client will continue to process the "old way" until the breaking event

> occurs.



i.e. in this respect, forms achieve the same thing as link relations

but in a more complicated way?



> In a space of several servers, using compatible representations, the use of

> the form can be used to allow, for example, a more sophisticated client to

> interact with a less sophisticated server.

>

> Consider the case of a purchasing agent wanting to forward credit card

> information. A modern server would likely want not just the normal CC info

> (number, name, exp date) but also that magic code on the back of the card.

> An older server may not require that extra code.

>

> A client that is capable and aware of that code would see that an older

> server is simply not asking for this information and will there for not

> provide it rather than just cramming it down the servers throat "because

> they all do this".



The problem with this is that it can be handled trivially on the

server side (by ignoring irrelevant parts of the client request), in

contrast to the complexity introduced on the client side by requiring

them to incorporate dynamic form interaction to their work flow.



Most people want to make life as easy as possible for their clients.

If there's a means to an ends resulting in less complexity for clients

it's very likely that will get picked - and rightly so.



> In the end, the client needs to understand how to interpret what it sees in

> the payloads, and well as how to populate the forms that are requested by

> the servers. The advantage of the forms is that it lets the servers be

> reasonably explicit as to what it wants without having to rely on the client

> simply "knowing". With friendly clients and servers, this makes the both

> ends of the interface much more evolutionary, and uses in band information

> to manage this to boot.



I disagree that the result is much more evolutionary. Afaict, omitting

and renaming the data produced by clients at run time is the extent of

the additional capabilities forms introduce. As I said above, I'm

unconvinced that the cost of adding significant additional

requirements to interact with your application outweigh the benefits -

particularly given that the benefits seem to be at best marginal, and

at worst non-existent.



Cheers,

Mike

Mike,



you have a very restrictive or biased views on forms, that may have been induced

by xforms or some other technology.



At heart, a form is only a mean to say to a client "i'll let you know where you

can put the data in that bit i give you", or sometimes "do as  usual but start

with this content", as well as some additional control data.



I'd argue that introducing forms and clients that can process them is a more

expensive solution that introduces an ability to change the server independently

of the client, and removes some of the domain-specific modelling from the media

type. Depending on your scenario that cost may be justified or not. HTML

browsers have full justification for this, and if you disagree that HTML forms

were a good thing then I'll just agree to disagree with you.



I'll also disagree that implementing form-based interaction has to be

complicated. Be it in a markup world or a json world, those things can be built

and extended fairly cheaply, and that includes using a small subset of xforms as

IanR has shown many times.



Forms are a tool that has proven itself valuable for those that have implemented

them, for their scenarios, and blanket statements are helping no one on this

list or elsewhere implement anything that matches their needs any better.





________________________________________

From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on behalf of

Mike Kelly [mike@...]

Sent: 25 October 2011 18:29

To: Nick Gall

Cc: Glenn Block; mike amundsen; rest-discuss; hypermedia-web@googlegroups.com

Subject: Re: [rest-discuss] Definition of a Hypermedia Client



On Tue, Oct 25, 2011 at 6:08 PM, Nick Gall <nick.gall@...> wrote:

> On Tue, Oct 25, 2011 at 12:54 PM, Mike Kelly <mike@...> wrote:

>>

>> On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:

>> > On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:

>> >>

>> >> If the link relations are dereferenceable URIs, you can use HTTP to

>> >> hint

>> >> to clients about the freshness of the semantics (i.e. with

>> >> Cache-Control,

>> >> ETags, etc.)

>> >

>> > Indeed. And that's a good practice. But it will only give you "hints"

>> > about

>> > the coupling and whether it is still "intact". It won't prevent breaking

>> > the

>> > coupling if you change the semantics. And it won't prevent the need to

>> > create a new link relation namespace if you want to enable new semantics

>> > while leaving the old namespace with its semantics intact.

>>

>> It does prevent the need provided the changes aren't breaking.

>>

>> Is that not enough?

>

> No. Inevitably, if the hypermedia interface is successful and evolves, some

> change WILL be breaking. That is the whole point of mnot's excellent blog

> post on the subject.



Right, the point being it gets you far enough so as there's no need to

be concerned about having to create an additional link relation for a

breaking change, as having to do so is reduced to the lowest rate

realistic/possible for a machine-consumed application.



On another note; I'm surprised nobody's preached the mystical

evolvability-inducing powers of 'forms' yet - apparently they solve

this problem. Or so we're told.. ;)



Cheers,

Mike





------------------------------------



Yahoo! Groups Links

I see. Then I would say the notion of one or more application roots

that the client is aware of is not an anti pattern.



Sent from my Windows Phone

From: Jan Algermissen

Sent: 10/23/2011 1:50 AM

To: Glenn Block

Cc: mike amundsen; rest-discuss; hypermedia-web@googlegroups.com

Subject: Re: [rest-discuss] Definition of a Hypermedia Client



On Oct 23, 2011, at 5:12 AM, Glenn Block wrote:



> I owuld add one exception to 1, which is the application root as there needs

to be some known uri which is the entry point of the application otherwise

you'll never access the application in the first place....



No necessarily because the client could obtain that URI from a

entry-point-by-service-type lookup (e.g. via DNS[1])



Nevertheless, I'd make clear (sort of as Glenn suggests) that clients

typically know entry URIs (maybe even many) of applications.

Furthermore, I'd make explicit that it is perfectly fine for clients

to keep those entry URIs for as long as they wish[2] (aka bookmarking)

and that this puts a responsibility on servers to maintain all entry

URIs over time ("Cool URIs don't change..." [3]).



Jan





[1] http://www.infoq.com/articles/rest-discovery-dns

[2] Until they see a 40 Gone for it

[3] http://www.w3.org/Provider/Style/URI.html





>

> On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:

> Great to see you fleshing this out. In terms of prior art, Darrel has done a

bunch of work around hypermedia clients with his Rest Agent stuff.

>

> A few other thoughts

>

> 1. A hypermedia client is not coupled to the uri space of the application /

does not contain hard coded logic for uris on the server.

>

> 2. A hypermedia client ignores hypermedia controls that it cannot handle / it

does not break by the presence of new hypermedia controls.

>

> 3. A hypermedia client advances application state by choosing from available

hypermedia controls in server responses.

>

>

>

> On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:

>

>

> ** cross-posted **

>

> I'm contemplating a working definition for a "Hypermedia Client." Here are my

first attempts:

>

> 1 - "A Hypermedia Client supports advancing it's own application state based

on application control information supplied in server responses."

>

> 2 - "A Hypermedia Client supports advancing application state by sending

requests to servers based on application control information supplied in server

responses."

>

> 3 - "A Hypermedia Client supports advancing application state by sending

requests to servers based on application control information embedded within, or

as a layer above, the presentation of information supplied in server responses."

>

> The germ of this definition is loosely based on a Fielding's description of

"Distributed Hypermedia"[1]

>

> The point of this exercise is:

> 1) Is there a generally agreed definition?

> 2) Can a definition be useful in evaluating/analyzing existing

implementations? (e.g. "Is 'this' a hypermedia client?")

> 3) Can a definition be useful in creating new implementations that "meet" the

definition? (e.g. "Here is what you need to build a hypermedia client....")

>

> Any/all feedback is welcome.  Possibly there is "prior art" here of which I am

unaware; please point me to any reference material you may think useful. Maybe

you've gone through a similar process and would like to send along your

experiences.

>

> Thanks in advance.

>

> [1]

http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1_3

>

> mca

> http://amundsen.com/blog/

> http://twitter.com@mamund

> http://mamund.com/foaf.rdf#me

>

> #RESTFest 2011 - Aug 18-20

> http://restfest.org

>

>

>

>

>

>

>

On Sun, Oct 23, 2011 at 12:39 PM, bruce.krakower

<bruce.krakower@...> wrote:

>

> Regarding evolvability, can we really say if new hypermedia controls should or

> shouldn't "break" a hypermedia client? This seems to get a bit fuzzy when a

new

> resource interaction may be required for a given application domain.



fwiw, yes, i think it's fair to say a new state transition offered by

the server shouldn't break a hypermedia client.  but then, i also

agree with mnot's principle[1] and I think the two are related.



"there is an underlying principle to almost any kind of of versioning

on the Web; not breaking existing clients."



Thanks,

--tim



[1] - http://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown

On 2011-10-25 04:15 , Tim Williams wrote:

> On Sun, Oct 23, 2011 at 12:39 PM, bruce.krakower <bruce.krakower@...> 

wrote:

>> Regarding evolvability, can we really say if new hypermedia controls should

or

>> shouldn't "break" a hypermedia client? This seems to get a bit fuzzy when a

new

>> resource interaction may be required for a given application domain.

> fwiw, yes, i think it's fair to say a new state transition offered by

> the server shouldn't break a hypermedia client.  but then, i also

> agree with mnot's principle[1] and I think the two are related.

> "there is an underlying principle to almost any kind of of versioning

> on the Web; not breaking existing clients."



maybe include some recommendation to think about this when defining

media types and link types, and to also document whether there are

"mustUnderstand" or "mustIgnore" semantics at work for extensions?



cheers,



dret.