It’s just data

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 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

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 at

shared 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.

Posted by Sam Ruby at

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 at

REST, 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

[from pauldwaite] Sam Ruby: Connecting

[link]...

Excerpt from del.icio.us/network/flangy 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 at

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.

Posted by Stuart Charlton at

The Hypertext Constraint

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...

Excerpt from Analysis from the Bottom Up at

I agree that “connectedness” does not capture it. A “-ness” form of a word isn’t how I’d expect a requirement to be phrased anyway.

But I also totally did not get “hypermedia as the engine of application state” until it was explained to me in-depth and ad-nauseum.

Why not “hyperlink-enabled”, or simply just “hyperlinked?” In reality, doesn’t that say it all?

Posted by Mike Schinkel at

The Hypertext Constraint

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...

Excerpt from Analysis from the Bottom Up at

Sam Ruby: Connecting

[link]...

Excerpt from Delicious/subscriptions/dynnamitt at

Sam Ruby: Connecting

[link]...

Excerpt from Delicious/subscriptions/dynnamitt at

RESTEasy: Where did the hypermedia go to?

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...

Excerpt from Guilhermesilveira's Blog at

pkeane: Roy F. and late binding as part of HATEOS http://intertwingly.net/blog/2008/03/23/Connecting#c1206306269

pkeane: Roy F. and late binding as part of HATEOS [link]...

Excerpt from Twitter / pkeane at

REST maturity model

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?...

Excerpt from Guilhermesilveira's Blog at

Modelo de maturidade REST

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...

Excerpt from Agile no mundo real at

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...

Excerpt from blog.caelum.com.br at

Modelo de maturidade REST

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...

Excerpt from Agile no mundo real at

REST maturity model

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?...

Excerpt from CaelumObject Developers' Blog at

Minimize coupling with REST processes

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,...

Excerpt from CaelumObject Developers' Blog at

Approaching pure REST: Learning to love HATEOAS

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...

Excerpt from kinderman.net at

thanks for this post a like this information Gambar Lucu

Posted by indonesiadalamtulisan at

Add your comment