Article: Mark Baker on Hypermedia in RESTful Applications

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

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.

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.

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-

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.

Ok, fair enough.

thanks,

JJ-

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.

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.

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

JJ-

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.

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