API Evolution - The hypermedia constraint?

At the recent Pnp Summit, during a presentation on Ado.Net Data Services, I asked Scott Hanselman whether it supported the REST "hypermedia constraint", to which he responded by asking me to clarify my question. At that point, and at several other times during the conference I realized that although I think I grok the concept, I certainly do a horrible job of attempting to explain it.

So I went searching and found a number of people who do a much better job of explaining it than I ever could. One of the advantages of a term so obtuse as "Hypermedia as the engine of application state" (HATEOAS) is that google does a great job of finding articles.

Stu Charlton explains HATEOAS from the perspective of an architect. My take away from this article is summarized by

making sure that your interfaces constrain the "when": logical timing & ordering expectations

Peter Williams suggests that hypermedia gives you the flexibility to change your URL structure without breaking clients.

Paul James gives a concrete example of how hypermedia helps to decouple the client and the server. The best line of this article for me was,

So next time someone goes on about how RESTful systems can't possibly work because they need some kind of description language to enable clients to be wired to servers, remind them of hypermedia and point them to any part of the Web for a real World example of REST in action.

For me I began to grok REST after reading Tim Ewald's post. For him REST only became significant once he understood the notion of a "state machine as node graph traversed via URI".

Too often REST is viewed as a HTTP/XML based data access layer. I think this wrong layer to deploy REST. REST for me is about exposing use cases/scenarios/stories to a non-human.

Maybe next time I get asked the question, I'll actually be able to remember the phrase "Hypermedia as the engine of application state" and I might even be able to explain it.