Article: Mark Baker on Hypermedia in RESTful Applications

Posted by Stefan Tilkov on Jan 28, 2008 05:31 AM

Community

SOA

Topics

REST ,

Design

Tags

Web services ,

Web 2.0 ,

Flickr

One of the constraints defined for the architectural style known as REST is "hypermedia as the engine of application state". In a new InfoQ article, Mark Baker, well-known for being one of the first who advocated the REST style instead of the mainstream web services approach, discusses what the hypermedia constraints means in practice and why it is essential to RESTful design.

According to Mark, the most important aspect of hypermedia is the usage of standardized identifiers - URIs in case of the Web - instead of proprietary identification protocols, and the application model that is enabled by them:

By using a common application model, one that is not just standardized, but fixed for all time, you are reducing coupling between consumer and producer by permitting each to evolve independently of the other. This way, old and new services can be combined together into a composite application, and old and new clients can be the ones doing that combining. I suppose we take it for granted in our use of the Web that one can simply include a link in a document to a page authored years ago and a consumer of that content can seamlessly navigate between them without having to download a new version of the browser. That's by design, not by accident.

Read the full article for more.

1. Back to top

   Bad example

   Jan 28, 2008 10:04 AM by Steve Jones

   Yes you can download a page from the link, but this doesn't mean you will be able to read it. After all the "page" could be a ".doc" file or an old Word Perfect file. Even if its modern HTML with CSS then there is little chance of it being legible on an old NCSA Mosaic browser. Just because I can link to something doesn't mean its usable. The assumption above appears to be that the "hyper" is more important than the "media".

   Reply

2. Back to top

   Re: Bad example

   Jan 28, 2008 10:30 AM by Stefan Tilkov

   True. But I can handle anything that has a media type I know (and have implemented logic for), which makes data and operations orthogonal concerns.

   Reply

3. Back to top

   Re: Bad example

   Jan 28, 2008 1:44 PM by Steve Jones

   This isn't quite true though either. For instance you might think you can handle video, but then find out you don't have the right codec. This is the same as the Mosaic "I can handle HTML" problem. Basically what you are saying is that in order to handle something you have to know about it before hand. I completely agree, but that isn't a run-time thing.

   Reply

4. Back to top

   Resource States

   Jan 28, 2008 3:35 PM by Jean-Jacques Dubray

   Mark: >> Some people mistakenly believe that "state" here refers to resource state, which would include, in this example, the balance of the accounts or the list of recent payments made. That isn't the case. I am sorry, but you seem to not understand the difference between the "content" of a resource and its "state". The examples such as "account balance" and list of transactions are "content" not states. States of an account include "opened", "blocked", "closed"... They have nothing to do with application state, even though the actions that are allowed on the account depend on the state of the account. I am disappointed by your article, precisely because you are not talking about the relationship between application state (i.e. an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations) and the state of the underlying resources. This is a much more difficult problem to deal with when compared to the problem of encoding "Query-by-example" behind a URI. QBEs are by no means are related to application "state" (i.e. the actions a user my take one a resource) but simply information navigation. You don't perform work when you navigate. QBEs are well addressed by REST and the Web. As you pointed out one can model the access to all the resources of my application with URI encoded QBEs. The biggest benefits include: they may become searchable and navigation links can be added to any of them without particular knowledge of their overall interface. You also did not speak about "events". There is no event model in REST. I have read recently someone claiming that it's okay to "GET the resource representation until something changes". BTW, this is what search engine do, they roam the Web for changes. Not very efficient, if you ask me. Since, when a resource changes "state", there is no practical way for a resource representation consumer to know about it. This reduces the application of REST to very short lived interactions when the resource of the state is not likely to change (and therefore the actions that are enabled don't change either). At the end of the day, the interface of a resource includes: - QBEs - Inter-Actions (to transition from state to another) - Events REST deals only with the first one, not the other two. JJ-

   Reply

5. Back to top

   Re: Resource States

   Jan 28, 2008 4:07 PM by Mark Baker

   JJ, the subject of the article is hypermedia, not on the relationship of application & resource state, nor "events", so please don't fault me for staying on topic! 8-O Also, the word "state" is well-defined in computer science and encompasses all the uses I've made of it in the article, including your different states of an account. I do have to disagree with you when you say "QBEs are by no means are related to application "state"", because with REST they are exactly that as a "query" is just a GET of a parameterized URI that was constructed based on directions previously provided by the server (as a result of a prior GET). Other architectural styles are free to do query differently of course.

   Reply

6. Back to top

   Re: Resource States

   Jan 28, 2008 4:28 PM by Jean-Jacques Dubray

   Ok, fair enough. thanks, JJ-

   Reply

7. Back to top

   Re: Bad example

   Jan 29, 2008 12:00 PM by Patrick Logan

   The fewer choices you have and the more your system knows about the choices it does have, the more usable this feature. Yes? I think the point is fair -- this is not Big AI. This is making the most out of what you've got at hand. The alternative is a lot more special purpose, one-off coding.

   Reply

8. Back to top

   Re: Resource States

   Jan 29, 2008 1:27 PM by Stefan Tilkov

   JJ, it seems your definition of "resource" is a different one than Mark's (or the REST dissertation's). The distinction of "content" and "state" is simply not part of this definition, which I don't see as a shortcoming, just as a difference. Regarding the use of polling to do eventing, I have to say that I disliked it at first, having been used to things such as JMS pub/sub, CORBA Event service, etc. But in conjunction with HTTP's caching/conditional GET support, querying for changes scales massively and is a great solution if you can live with the latency. For anything but high-performance/soft realtime scenarios, I know prefer to simply publish Atom feeds because of the simplicity and scalability.

   Reply

9. Back to top

   Re: Resource States

   Jan 29, 2008 4:06 PM by Jean-Jacques Dubray

   thanks, this is an important information because as you mentioned it is not intuitive that it would scale. JJ-

   Reply

10. Back to top

    Re: Bad example

    Jan 29, 2008 4:37 PM by Steve Jones

    Is it more coding? Or is it actually the same amount of coding just done in another way? You don't actually have fewer choices just because you have a reduced vocabulary, that can just mean its more complex to do the same thing because it takes more interactions. If we are talking about dynamically changing complex systems, such as VMI or Financial Trading then the phrase "big AI" is probably exactly what we are talking about.

    Reply

• Older >