BT

Article: Mark Baker on Hypermedia in RESTful Applications

by Stefan Tilkov on Jan 28, 2008 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Bad example 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".

Re: Bad example 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.

Re: Bad example 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.

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

Re: Resource States 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.

Re: Resource States by Jean-Jacques Dubray

Ok, fair enough.

thanks,

JJ-

Re: Bad example 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.

Re: Resource States 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.

Re: Resource States by Jean-Jacques Dubray

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

JJ-

Re: Bad example 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.

Useful media types by Mike Kelly

This may be of interest to readers:

I've written a media type called HAL that can be used for APIs similar to the way HTML is used for web apps, read more here:

stateless.co/hal_specification.html

The JSON variant is now in the process of being turned into an Internet-Draft, and the latest version is available here:

raw.github.com/mikekelly/hal-rfc/master/draft-k...

Hopefully it's of use to someone!

Cheers,
M

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT