Re: YAATRTA HATEOAS
- On Wednesday 03 June 2009, Nick Gall wrote:
> In the never ending quest to replace the acronym HATEOAS withI've read your posting and Jim Webber's presentation you're referring
> something more intuitive and pronounceable, I humbly submit Yet
> Another Attempt To Replace The Acronym (YAATRTA) HATEOAS: HYDEPR
> (HYpermedia DEscribes PRotocols). Credit goes to Jim Webber for
> coining the term "Hypermedia Describes Protocols". My "value add" was
> simply to turn it into an acronym: HYDEPR (pronounced HIGH-de-pur).
> (Hey, that's what analysts do. :-)) Here's how to use it in context:
> "Perhaps the most important RESTful 'uniform interface' constraint is
> the HYDEPR constraint (formerly known as the HATEOAS constraint)."
> Read this post for more information: Epiphany: Replace HATEOAS With
> "Hypermedia Describes
>lace-hateoas-with-hypermedia-describes-protocols/> -- Nick
to. For maximum impact I'll put it very boldly and far beyond my level
of understanding: HATEOAS by any other name is a pipe dream. The server
can put all kinds of links into its responses, but that doesn't do any
good unless the client knows what to look for.
So, looking at Jim's restbucks example, how does the client know to look
for LINK elements with rel="payment"? If this isn't a protocol I don't
know what is. Sure, some interactions are lifted into a generic protocol
of interaction with resources. That doesn't mean the protocol isn't
there from the start. If the client doesn't know about the protocol it
is paralyzed for it has no idea which of the available links to follow
to achieve an intended effect.
HATEOAS provides a level of indirection between state transitions and
their associated endpoints. HATEOAS provides a generic way to indicate
available state transitions. These are worthwhile features, but that's
- On Sat, Jun 6, 2009 at 8:39 AM, Roy T. Fielding <fielding@...> wrote:
> On Jun 6, 2009, at 12:40 PM, Nick Gall wrote:
>> I thought REST was the STYLE! Now we have the style of a style? I.e, REST is substyle of the hypermedia style?
> REST is a composition of constraints that come from many styles.
>> So I went back to the thesis to see how you defined hypermedia only to discover that you don't. AFAICT there is only one definition constraining hypermedia in your thesis: Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. (I notice that assertion is not footnoted.)
>> This sentence really doesn't help since it uses the phrase defined by not defined as.Thus, the sentence doesn't say what hypermedia is, it merely imposes a constraint on the concept of hypermedia -- whatever it may be. Nowhere in the thesis is hypermedia (style) ever cited or defined. Or is hypermedia not a style but the single architectural constraint provided by the quoted sentence? All this kind of makes it a moving target.
> *shrug* I didn't think it needed to be "defined as" (at the time).
> Too many of my friends are experts in hypertext research and they
> probably would have poked mercilessly at my final defense.
>> [Current debate aside, I'd be really interested to hear your definition of hypermedia, or even just see some pointers to others' definitions that define it as an interaction style. All the definitions I've ever seen define hypermedia as a kind of media. Even Ted Nelson defined hypermedia as simply the medium, not the style.]
> See slide 35 (pp. 50-53) of
Thanks for the pointer. It was immensely useful. I recommend EVERYONE interested in REST read it. Is there audio of this talk anywhere? I'd love to hear the details about these slides.One question I was about to ask you is apparently answered in this pitch. HATEOAS can be replaced with HITEOAS:"Hypermedia IS the Engine of Application State." (see slide 75)I find IS far clearer than AS. I think others will as well.>> All that being said, my argument still holds. Even if hypermedia is defined as an interaction style (or something like a style) as opposed to a particular kind of media (data), a style is no more an engine than a set of HTML documents is an engine.>
> Oh, really? I wonder what you think engine means.
> An engine is a system for transforming input into some form
> of output. The engine in a car is a system for transforming
> gasoline into torque that can be applied to a drive axle.
> My little bullet of a constraint
> "hypermedia as the engine of application state"
> does not say that the engine is a hypertext document. It describes
> the engine as being a hypermedia system, much like a car's engine
> would be described as an internal combustion system.I think its fair to say that your thesis is vague regarding what hypermedia refers to. When "hypermedia" is used as a noun and not as an adjective (eg hypermedia document, hypermedia link) it is not clear what it refers to. The same thing is true in the presentation you link to above. On pages 50-53, you highlight three different definitions of "hypertext", none of which specifically refer to a system. The first two (Nelson's and Conklin's) specifically refer to hypermedia being a "text" and a "medium" -- not the complete system surrounding such text/media. So even if YOU mean hypertext/hypermedia=complete system (not just the media of the system), most people won't know that -- hence the confusion I've been alluding to from the beginning of this thread.Even your definition can be read as referring to just the documents/text/media:
When I say Hypertext, I mean ...
There is NO mention of the entire system. The focus is on blending controls into information, aka a medium. "Hypertext does not need to be HTML" suggests that hypertext can be another kind of document (eg XML document). Roy, you have to admit that most people (even most developers) think of hypermedia as a kind of document or media -- not the entire system surrounding such media. Even wikipedia defines hypertext as the text, not the system. Thus, when they first hear "hypermedia is/as the engine of application state", they're going to think that a document or set of documents is the engine. Yes, this initial misunderstanding can be corrected by further explanation, but why cause the confusion in the first place by using a term "hypermedia" that most people interpret as referring to the documents/media. Why not at least change the term toHypermedia System IS The Engine of Application State?You use the term "hypermedia system" extensively in your thesis so there shouldn't be a problem with adding "system" to the term to clarify your intent. (BTW, One would think that if "hypermedia" alone referred to the system, that "hypermedia system" would be redundant.)>
- The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions.
- Hypertext does not need to be HTML on a browser
- machines can follow links when they understand the data format and relationship types
> I did not cite any specific reference for that because (AFAIK)
> there doesn't exist any specific reference. I was doing synthesis.
> Nelson's definition is tied to what he cared about -- non-linear
> writing as a form of poetry. Conklin was entirely focused on
> graphical user interfaces, so his definition is tied directly to
> GUI affordances. My observation is something that I considered
> to be inherent in the design largely because the Web was based
> on Engelbart's view of hypertext, but AFAIK Engelbart never actually
> defined the term other than by how it was used in Augment/NLS
>> To support this claim, let me quote further from the paragraph in which the above quoted sentence appears (4.1.3):
>> Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. Distributed hypermedia allows the presentation and control information to be stored at remote locations. By its nature, user actions within a distributed hypermedia system require the transfer of large amounts of data from where the data is stored to where it is used.
>> Yet again, we see that it is user actions (powered by the browser software) that singled out as driving the application ("user actions ... require the transfer of ... data") -- the system does not drive itself.
> User actions are part of the system being designed. That paragraph
> is talking about a design constraint imposed by the requirement that
> the information be distributed all around the world. Aside from using
> the same term in two different ways, I don't see how that has anything
> to do with your point. Whether or not the system drives itself is
>> Saying that hypermedia (the entire system or style) is the engine is like saying the entire automobile (or the architectural style called "automobile") is the engine. It may be true in a Zen-like way (and believe me, I LOVE mystical philosophies), but it is utterly confusing to 99% of humanity.
> 99% of humanity was not my audience, and I'll hasten to bet that less
> than 1% of humanity knows what an engine means even for something as
> mundane as an automobile.
>> It is far clearer to the rest of humanity to say that the browser (or more generally user agent) is the engine of state, the user is the driver of state, and hypermedia is the representation of state.
> The only reason that is clearer to the rest of humanity is
> because it is wrong. It's like saying the Web is defined by
> what a user sees in MSIE. I don't care how easy it may be for
> a non-educated user to understand that definition: it is wrong
> and I have no interest in peddling simplified forms.I shouldn't have referred to 99% of humanity. I should have said 99% of developers are confused by HATEOAS and would be utterly confused by the statement that the entire hypermedia system, including the user, the browser, the server, etc. is the engine. If the entire set of components, connectors, and data that constitute a hypermedia system are collectively the engine, that doesn't really help us deal with where state should be stored or processed. State could be diffused throughout the entire system. Since the entire system is the engine, then the application state it is transforming exist anywhere in the system. But we know that REST does not allow that, since all application state must be on the client.Let's look at how you describe HITEOAS on slide 49 to see if that helps the current discussion:REST Uniform InterfaceHypertext as the engine of application state
Allow me to tease out some possible implications of these assertions (do you agree with these?):
- A successful response indicates (or contains) a current representation of the state of the identified resource; the resource remains hidden behind the interface.
- Some representations contain links to potential next application states, including direction on how to transition to those states when a transition is selected.
- Each steady-state (Web page) embodies the current application state
- simple, visible, scalable, reliable, reusable, and cacheable
- All application state (not resource state) is kept on client
- All shared state (not session state) is kept on origin server
One thing I love about implication (9) is that it calls to mind the old adage "Man proposes but God disposes." In the case of REST, "the server proposes (application state transition options), but the client disposes (by selecting among the options)." Ted Nelson even refers to this adage in an interview: "I think of it as a form of writing - and writing is essentially what I would call a two-God system, because God the author proposes and God the reader disposes. The author is completely free to do anything on the page that he likes." Thus the server guides but does not control the client.Since it is always the client that initiates application state changes by sending a new request to the server, it seems completely intuitive to me to view the client as the engine. Just as the engine in a car initiates the state change of the axle. Thus, for those who prefer an acronym with "engine" in it, I think the following convey more clearly what is going on:This discussion clarified HATEOAS a lot for me. Thanks Roy and everyone else.
- Not all representations must contain links to next possible application states -- contrary to some descriptions of HATEOAS by others
- Besides links to next states, the representation may (must?) contain metadata on how to transition to those states
- The current application state is completely embodied in the set of representations that constitute a web page (eg including inline representations)
- No resource state is kept on the client
- Only representations of the resource state are kept on the client
- No application state is kept on the server
- Potential application states are generated on the server and returned in resource representations
- Since all application state is kept on the client, only the client can initiate a state change
- The server generates state transition options and the client selects them
- The server can never initiate a change in application state
- The server can provide potential application state changes to the client
- The server can only initiate a change to a resource's state
- The client can only initiate a change to a resource by requesting the server initiate the change
- Application state is not shared state
- Application state is private to the client
- Client is the Engine of Application State Transitions Represented as Hypermedia Links (CEASTRAHL)
- Client Traversal of Hypermedia Links Is the Engine of Application State (CTOHLIEAS)
- Client is an Engine Driving a Hypermedia Representation Of a Protocol (CEDHROP)
- The Engine of Application State: Server Generating Representations With Data-Guided Controls & Client Selecting Them
AOL IM: Nicholas Gall
Yahoo IM: nick_gall_1117
MSN IM: (same as email)
Google Talk: (same as email)
Email: nick.gall AT-SIGN gmail DOT com