In the last Northeast Roadshow series, we spent a great deal of time discussing what makes a service…

I was a fan or Mr. Burke when I was a kid (to the side of Carl Sagan’s Cosmos). I actually own the Connections PC game! And the fun part is I usually talk about the show in my classes at the university, to clarify points and make the class less boring.

Another fun part is that I always start my Software System Architecture Fundamentals course asking the students about the latest technologies, buzzwords, concepts and magazines. The result is always straight faces meaning they do not know (or haven’t hear of) the latest terms or concepts. And as you mention, many people expect someone will read the scientific/technical stuff and explain it to them. So the first class is a motivation to start reading!

With REST, I come to find many of them have heard of the word. For them, it is a way to create webservices using HTTP post and get. And I don’t blame them. I recently came across an article of one of the creators of Groovy (Scott Davis) that correctly explains several points of REST (Not RPC, resource-oriented, etc), but starts saying your dissertation “outlines two approaches to Web services: one that’s service-oriented and another that’s resource-oriented”. He may mean your dissertation outlines the resource-oriented style for network applications, but unless there is a revised version of it, I didn’t see anything related to web services in it! So, if the street engineer (the one that will not read your text) reads that, the idea of the dissertation talking about REST web services and the evil SOAP would be perfectly normal.

Actually, due to that article, I was moved to start a set of blog entries, to comment on your dissertation. Not to explain it (although a summary of each chapter is mandatory), but to comment on the concepts and findings. Of course, by the time I read it, I had a list of things I totally agree with, some I disagree a little, and some that I noted down in case I may find Roy T. Fielding sitting near by taking a coffee break, and in the mood of discussion, to ask him about.

Cheers

William Martinez Pomares.
Architect’s Thoughts

(1) If Site A and Site B each use proprietary APIs to provide a list of friends I must instruct my software twice to grab a user’s friends in two separate manners.

(2) If Site A and Site B each use RESTful APIs I must only instruct my software once to achieve the same result.

Scale to 10 sites and (1) has been forced to develop 8 more proprietary connections while (2) has done nothing extra.

Zoom on up to web scale and the implications seem obvious. Over-generalizations and security issues aside, is this not a simple description of one of the very many possibilities proper RESTful interface design may offer?

I’m young (23), inexperienced (no formal CS), and uneducated (no degree). I first read both your dissertation and Tim Berners-Lee’s Weaving The Web years ago. Since then I’ve reread them each several times and believe that I understand enough to recognize a fundamentally flawed “REST-like” API when I see one. If I can grok it, an engineer/architect with a $75k+ salary and a fancy title should be able to as well.

This brings me to my concerns in regards to proper REST adoption. I have seen countless independently owned and operated sites utilize good design principles awhile the large companies totally skirt the issue. Do they have bigger and better things to worry about?

It seems as though larger sites hold on to a tight, proprietary API in order to “better protect” (their thinking not mine) their assets. Could you care to reflect on this issue? That is, should they have any excuse to favor an RPC-based format over true REST in the name of security or privacy? I believe this to be a non-issue as secure implementations could stem from either. What are your thoughts on simplicity of client design in this same situation? I truly believe the client design would be simpler as well. Heck, I’d think their scalability issues could be addressed in the process as well. Basically I question whether it’s lack of awareness or lack of desire (good or evil).

I understand it’s difficult for you to spend time considering particulars when taken out of context so general answers will suffice. Thanks for any input.

With all due respect, I think you’re continually going to encounter that contingent that is expecting the bullet list of instructions, or even lazier, the screencast of ultra-practical steps to make the baubles twirl on their displays. My only consolation is the notion that this is probably just a symptom of the industrial age’s death rattle, and it’s anomalous that this behaviour is even considered acceptable.

I like to look at it this way: if they don’t understand, it’s their loss, and unless you’re trying to pitch them, it may not be worth suffering the attempt.

What I mean is, the tandem of open source software and the Web has helped turn consumers into producers – and this, overall, is a great thing. A side effect of this phenomenon, however, is that the great majority of those affected are still divorced from the notion that theory and the conceptual integrity derived from it are in fact responsible for the practical bits they can tweak.

I also suspect that another contributing factor is continuous partial attention, which I think drives most of this ADD neophile behaviour. I, for one, am quite confident that this will eventually die down. It has to. (As to why, listen to the excellent treatment by the term’s progenitor, Linda Stone, which can be heard in the first MP3 on this page.)

When I think of REST, I think of a large, nebulous, slow-moving concept, from which other, harder, faster-moving concepts are derived. In the parlance of Frank Duffy, and later popularized by Stewart Brand in his excellent book and subsequent documentary How Buildings Learn, REST would be the site in their strata of shearing layers. HTTP (and presumably Waka) would be structures.

That said, some more Fisher-Price notation, such as a Venn diagram depicting the relationships, might be of some use.

I personally lament that it took me so long to psych myself up to read your dissertation (which is a great read, by the way), which I did last year. The funny thing is, when I read your other work like RFC 2616 or observe the design of the Apache response chain, I see REST. I could only have benefited if I had just done so earlier.

As for the punters, they seem to learn in a hurry when you start eating their lunch.