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 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.
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.
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).
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.
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...
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...
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?
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.
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...
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.
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?
Leonard, 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.
I have spent quite a bit of time recently designing a system in the REST style. Two main observations from that process: Web search is still pretty terrible once you need something more than a company’s homepage or a wikipedia entry. There is...
I have spent quite a bit of time recently designing a system in the REST style. Two main observations from that process: Web search is still pretty terrible once you need something more than a company’s homepage or a wikipedia entry. There is...
Some friends have asked what are the major differences between Restfulie and RESTEasy client frameworks. Strong coupling and hypermedia awareless As of today, Resteasy requires you to create an interface mapping every resource operation to a...
Not yet REST How do we achieve REST? Leonard Richardson’s model was widely commented and Martin Fowler posted on “Rest in Practice” (a book I recommend reading). But what is left out from REST in Richardson’s model and why?...
Ainda não é REST Como alcançar REST? Quão maduro é a minha aplicação em relação a REST? O modelo de Leonard Richardson foi amplamente discutido e comentado, inclusive no “Rest in Practice” (um livro que recomendo a leitura). Mas o que...
Diminuindo acoplamento de sistemas com REST, e video!
Muitos ainda me perguntam qual é a real vantagem do REST sobre os modelos mais tradicionais . Ao integrar sistemas, a implementação de acesso ou de processos costuma ser feita de maneira sequencial, onde esperamos resultados específicos de nosso...
Ainda não é REST Como alcançar REST? Quão maduro é a minha aplicação em relação a REST? O modelo de Leonard Richardson foi amplamente discutido e comentado, inclusive no “Rest in Practice” (um livro que recomendo a leitura). Mas o que...
Not yet REST How do we achieve REST? Leonard Richardson’s model was widely commented and Martin Fowler posted on “Rest in Practice” (a book I recommend reading). But what is left out from REST in Richardson’s model and why?...
While integrating systems, implementing access or processes is typically achieved through man ordered list of steps, where one expects specific results from the server. Expecting specific results means coupling your client to a servers behavior,...
We’ve been building up a REST API at work for a couple of months now, have an iPhone client, an Android client, and a browser-based client built on it, and are well on our way to using it for a number of other purposes. As far as client and API...