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.