You’re correct. I’m thinking of classic enterprise integration scenarios. I think REST can really shine here as well, but there is still *a lot* of work to do. We need to take techniques, patterns, and services defined in these traditional environments and iterate on them over and over again to see where REST can improve things. This is the main reason REST-* (rest-star.org) was created. To figure out where these classic enterprise idioms intersect with REST.

My first reaction is that this feels almost like we are arguing over moving goal posts. I don’t think there’s a disconnect, or any disagreement that machine-based decisions are based on a set of finite rules, even from Roy, at least I’ve never read any such thing from him. A browser makes dynamic decisions to transform and render multiple media types onto a screen, which renders the state of the hypertext application. But it does not normally make decisions that enact state transitions on the resources themselves, because that’s what the human is for.

On the other hand, can we think of machine agents that do make transitions on the resources themselves? There are a few, usually mashups and/or thick front-ends to RESTful APIs, but they’re certainly not as pervasive. I think the issue may be that you see limitations of the current Web architecture for the problems you’re interested in (e.g. classic enterprise integration scenarios), and there is a frustrating lack of admission of the amount of work that remains to address them.

To me, a RESTful interface for changing resource state is not very different, IMO, from dynamic interfaces such as CORBA DII, or COM Automation, or RMI with Reflection, or even SOAP sans WSDL — with the exception of uniform method & return code semantics, and that there’s a limited amount of out-of-band information required to access the interface description – GET often suffices. But there is no magic here, it’s just an interface, little different from those we use in other technologies. The main benefit is that it presumes a dynamic interface by default, one that can be introspected, instead of hard-coded against. A RESTful toolkit presumes a dynamic interface by default instead of as a bag on the side, as with normal CORBA stubs/skeletons, or COM vtables, or RMI Remote interfaces.

When you presume a dynamic interface by default, it enables freedom for an agent to have much more varied decision making behaviour than just if-then-else statements. We’ve seen plenty of evidence for this on the agent-side with the use of GET, we’ve seen less evidence of this on the resource-side with automated use of POST/PUT/DELETE, mainly because it’s so dependent on building a modular set of media types to achieve broad interoperability. Comprehension and standardization here has been glacial, and the REST community does often downplay the large amount of effort still required to bring the “write” side of the read/write web up to par. This remains frustrating.

Not sure I articulated well enough. But, again, IMO, browsers are a horrible example as they don’t drive state transitions, which is a huge points that many RESTafarians miss. They only render, which basically means they are a transformation engine changing (X)HTML into pixels.

I also agree that too much definition can be done at times. But as in regular software development bad engineers will never worry about backward compatibility or fluidity. Same is in regards to custom media types.

Yeah, web browsers do a lot of nice things, but what they don’t do is make decisions. Humans do that. Machine-based clients need to make decisions based on a preset finite set of rules which are decided upon ahead of time. A human using a browser can basically follow any link rendered by the browser they want. I think this is a fundamental disconnect that a lot of RESTafarians make. Including Roy.

Anyway, yes, I agree with most of your points, and think you’ve really hit it with #1 (hypermedia), #2 (the importance of URIs, but also that we haven’t solved all problems here), and #4 (which I would term a restatement of ‘design for serendipity’).

I also think that for Clouds, and IT Management, it’s all about linked data.

Regarding MIME types, well, there are limitations to them, and we run into them especially when we start applying REST to more and more data variants or custom (i.e. business) data structures. They were designed in a different (pre-Web!) era, and it’s wonderful they’ve lasted this long, but surely something new must come along to supplant them.

And a response to Bill Burke, whom I’m not sure will be reading this:

“A machine client is not capable of making decisions on the fly. Things have to be pre-defined up-front for a machine-based client to work. ”

This is true to a point — but just a point, and an evolving one. The tendency among the integration crowd has been to pre-define things way, way too much, in a way that drastically limits the amount of forward compatibility.

Think through the evolution of data integration, from fixed-format data files with zero self-description, through comma-delimited files, through labeled delimited files, RPC formats, DII or Reflective calls, tagged data, and SQL or ETL-based integration. ETL tools out there weren’t coded against a particular schema, and are capable of doing backflips with one’s data.

“Maybe I’m just horrible at REST, but I don’t see the “dynamic decision making” capabilities of links making such a big impact in machine-based clients.”

See, this I disagree with, as it’s one of the major drivers behind REST’s loose coupling. There is plenty of evidence abounding that a machine can make a dynamic decision based on a link. Your web browser does it all the time when it interprets DIV tags relative to CSS, or what algorithm to use to render an IMG when it gets the MIME type of that image (or sniffs it . RSS/Atom aggregators do it all the time as well — what do they do with alternates? How do they render them? It depends.

“There’s too much “black and white” going on in the REST community. It seems you either are or aren’t REST and you better not dare call your application or API RESTful if you aren’t 100%.”

The main problem is in devaluing the term. If someone puts together a crap API, and it’s objectively bad (i.e. breaks the semantics of HTTP), then it’s worth calling that out.

On the other hand, the constant bickering about “purity” through PUT vs. POST or URI syntax and parameter-laden URIs are IMO games for chumps. They matter, but not much.

Expose the graph of resources as LinkedData, leverage lots of existing semantic web tools to drive the domain modeling, i.e. OWL, manipulate the graph RESTfully, and add a SPARQL endpoint to allow the graph to be queried. A small illustration of this for IaaS is at http://fujocci.appspot.com/iamsecret

A small point on your question #1: as RDF is a infoset kind of thing, there are many different serialisations of this: XML, text, JSON … all of which are the same list of triples when it comes down to it. I’m not sure if that is a path to legacy hell anymore (?)

1) This idea of self describing messages just doesn’t work very well for machine-based clients. Self describing messages work very well for browsers because a human is driving state transitions. A human is capable of making decisions on the fly based on rendred content. HTML has worked so well with little constraints because a human is driving the interaction.

A machine client is not capable of making decisions on the fly. Things have to be pre-defined up-front for a machine-based client to work. This is especially true of error conditions. This doesn’t mean REST principles aren’t useful for machine-based clients, it just means that these core principles are applied a little bit differently. For instance, I’ve found that links are more useful as a “Naming Service” replacement than a way to give a client options for state transition. That links real purpose in machine-based clients are to make URI’s opaque. Maybe I’m just horrible at REST, but I don’t see the “dynamic decision making” capabilities of links making such a big impact in machine-based clients.

I think a huge arrogance of the REST community involves in not thinking about machine based clients because much of the success of the web has been human-client driven. There’s going to be a bit more up-front predefinition for machine-based client consumption of REST services. Which brings me to my 2nd point…

2) There’s too much “black and white” going on in the REST community. It seems you either are or aren’t REST and you better not dare call your application or API RESTful if you aren’t 100%. What drives me crazy is not even the Web itself is 100% REST. The vast majority of applications (I’m not talking about websites but applications) on the web do not conform 100% to REST principles. They use GET to change resource state. They rely on having a session with the server. They overload POST by tunneling mini-RPCs (think of the action URIs in Struts for example). If you truly look at the success of the web, its the hypermedia aspect of it that is the underlying cause, not a uniform interface, and surely not stateless interaction with resources. What boggles my mind is that these same fanbois that call your interface unRESTful if you’ve had to bend a principle are the same people that promote REST as being the architecture of the Web. This is pretty much why I’ve completely unsubscribed from the rest-discuss list. It is just too aggravating to listen to all these people describe web services in terms of black and white and not grays…

Anyways, sorry to rant. Interesting blog post.

Mitch