Connecting
Roy Fielding: ROA is supposed to be a kind of design method for RESTful services, apparently, but most folks who use the term are talking about REST without the hypertext constraint. In other words, not RESTful at all. REST without the hypertext constraint is like pipe-and-filter without the pipes: completely useless because it no longer induces any interesting properties. The RESTful Web Services book doesn’t help the situation by renaming the hypertext engine as connectedness. That does nothing but obscure its role as the driving force in RESTful applications.
I won’t take credit for that idea, but I stand behind it. Perhaps I talk to different people than Roy does, but many of the people I do talk to don’t, um, connect when they hear the phrase hypermedia as the engine of application state. Yet, when I point out that systems that are set up to merely enable the storage and retrieval of discrete and disconnected resources aren’t crawlable, and therefore effectively are not part of the web, well, lets just say that I find that sentiment resonates better.
I agree that “hypertext as the engine of application state” is completely obtuse. I tend to prefer the made up term “linkability”. Connectedness makes me think of a network connection instead of connecting resources together through links.
Posted by Dan Diephouse at
I agree completely. RESTful Web Services made the benefits of hypertext far clearer to me than Fielding’s thesis did.
Posted by Matt Brubeck at
The problem is that just being connected is not enough. Yes, it is important, and I’d love to have five or six different ways of explaining the parts of REST that are intended to help grow the Web. But hypertext as the engine of hypermedia state is also about late binding of application alternatives that guide the client through whatever it is that we are trying to provide as a service. It is fundamental to the goal of removing all coupling aside from the standardized data formats and the initial bookmark URI. My dissertation does not do a good job of explaining that (I had a hard deadline, so an entire chapter on data formats was left unwritten) but it does need to be part of REST when we teach the ideas to others.
I like the book’s emphasis on applying REST in practice and running through real examples. Dissertations are not so good for teaching people how to do something (other than to write more dissertations).
Posted by Roy T. Fielding atshared an item on Google Reader
Connecting 4 hours ago - Comment...Excerpt from Edward O'Connor - FriendFeed at
Dan: forgive me, but “linkability” mostly misses the point. The post of Roy's that this one is a response to makes that point that we are seeing an increased number of “ROA” systems that have things that, while theoretically linkable, in practice are not actually linked.
Roy: got it. “connectedness” is but a half or quarter step forward at best. HTML forms have an action which “connects”, but that is but a small portion of the value of forms. The fact that the client downloads the definition of the various text, radio, submit, etc. controls on every request virtually eliminates the need to do installation and updates for web applications.
I also don’t think connectedness is enough, it doesn’t explain the role of server-directed transitions. But for what it does describe, it’s an excellent term that people (the ones I talked to about REST) intuitively grasp.
Connectedness also has the nice side effect of connecting (no pun intended) with the people who approve your budget.
Posted by Assaf atREST, Design, and Late Binding
Roy Fielding’s latest post discusses the differences between software implementations, architectures, and architectural styles. Having spent the last few months rewriting DASe to adhere more closely to the REST architectural style, I have come...Excerpt from Peter Keane's Miscellanea at
REST, Hypermedia, and JSON
Enjoying Sam Ruby ’s latest post titled Connecting , I was reminded that designing a RESTful system means much more than just adhering to a uniform interface (often the first attribute of a ROA that is promoted). When designing a Resource Oriented...Excerpt from Planet RDF at
Is the difference between “connectedness” and “linkability” the difference between “uses links” and “can be linked to” or has some of this gone over my head?
Posted by Dare Obasanjo at
Dare: when I last looked at Web3S, I came to the conclusion that Web3S data is further constrained to be a self enclosed tree. There is no general concept of a hyperlink in Web3S, neither to external data, nor within a tree. Yes, you could link to Web3C, but it provided no mechanism to link back. That’s kinda unweblike. It was linkable, but it could not connect.
Posted by Sam Ruby at
nodalities: This Week's Semantic Web
Selected links related to Semantic Web technologies for the week ending 2008-01-07, all weeks . Also available in RDF as linked data or via GRDDL . No obvious themes this week, but still lots of activity in diverse areas. So instead of introductory...Excerpt from Planet Code4Lib at
[from harryf] Connecting
“hypermedia as the engine of application state” ... enables crawlability...Excerpt from del.icio.us/network/Buetti at
Fair enough. I see both Sam’s and Roy’s points here. I just wish someone would come up with a better term. While HMAEAS is right on, it fails to communicate the idea to the general audience. Links are understandable, but don’t imply the engine of application state. Connectedness seems to imply TCP-connections to me.
Posted by Dan Diephouse at
Excuse me for being obtuse, but I’m still trying to understand what’s being discussed here --- that is, what HATEOAS actually means, and how exactly it differs from plain conectedness.
My current mental model looks like this:
1. The book term “conectedness” means that the resources exposed by the service have hyperlinks to one another. If you draw them as a graph, the whole graph is a single connected component.
2. “Application state” means whatever state is specific to the server-client interaction at hand; in other words, state that’s only visible to a specific client.
3. “The hypertext constraint” Roy’s talking about in his post means the same thing as “hypermedia as the engine of application state” in his thesis.
4. And HATEOAS means that the changes in application state are performed through hyperlinks.
5. Thus, HATEOAS implies the following requirements:
1. All the possible application states are exposed as resources (and not implemented e.g. with cookies, javascript variables and whatnot).
2. All the possible state changes are exposed as hyperlinks. This implies conectedness, but is a stronger restriction.
6. Compared to simple conectedness, HATEOAS has the added benefit of “late binding of application alternatives” (Roy). In other words, the path you take in the state graph is only decided at runtime, when you’re actually using the application, and the server can present new states and transitions. These “server-directed transitions” (Assaf) are how HATEOAS “eliminates the need to do installation and updates for web applications” (Sam).
Does that look right? Am I missing any other HATEOAS benefits over conectedness?
Posted by Leonardo Boiko atLeonard, I think you’ve nearly summarized it, though I understand the “application state” requirements a bit differently:
An agent’s application state is the current “set” of representations it has. It’s not just one representation.
For example, in a web page, the HTML resource is not the only application state, but the IMG, SCRIPT, and OBJECT links form part of that state too (yes, including JavaScript variables). And there can be local manipulation of the state (that’s what mobile code like JS does), but that doesn’t describe the operation of the application over the network, so isn’t necessarily very interesting from a RESTful perspective.
An agent is told to sense one resource, and then goes on to sense/read several related resources, and then “stops” once it’s had enough — reaching a steady state. It then prompts the user (or decides itself), and picks the next state to go to, which just be be more sensing (i.e. page surfing), or may be a modification of a resource’s state (i.e. submitting a form). We consider the ‘current application state’ to be the most recent resource we picked + its relatives that we deem appropriate based on their link context (e.g. IMG is OK, but A is generally not, per HTML). The agent doesn’t forget where it’s been, but past resource state might be out of date (they’re “historical application state”, perhaps).
On the general topic, personally, I think connectness is a good, useful term, but my “aha!” moment didn’t come from it. It was realizing “networked hypermedia” was an abstraction that’s more powerful than plain-old message passing, but still supports object-orientation. The main difference (to me) is that It treats “data” as a first-class citizen, not as arbitrary lumps in a pure message-passing architecture where the endpoint, topic, or service is the first-class citizen. Database folks should be rejoicing.
I’m not sure there’s anything we can do about the obtuseness other than build consensus and education on what “networked hypermedia” is. I think our industry’s problem is more of a case of the difficulty of “unlearning” all of the low-level tricks we know in the message passing arena, at least when working at scale.
Posted by Stuart Charlton at
I think page 96 and figure 4-4 in the book do a pretty good job to exemplify the connectedness/hypertext issue.
Rather than disputing on names, it would be much more interesting to see if the underlying concepts entail the same set of consequences/properties. If that’s the case, new names may indeed just help understanding as well as hurt it.
Posted by Giulio Piancastelli at