Fri 24 Oct 2008
Specialization
Posted by Roy T. Fielding under blogging, software architecture, systems engineering, web architecture
[6] Comments
As you may have noted, my last post seems to have hit a nerve in various communities, particularly with those who are convinced that REST means HTTP (because, well, that’s what they think it means) and that any attempt by me to describe REST with precision is just another elitist philosophical effort that won’t apply to those practical web developers who are just trying to get their javascript to work on more than one browser.
Apparently, I use words with too many syllables when comparing design trade-offs for network-based applications. I use too many general concepts, like hypertext, to describe REST instead of sticking to a concrete example, like HTML. I am supposed to tell them what they need to do, not how to think of the problem space. A few people even complained that my dissertation is too hard to read. Imagine that!
My dissertation is written to a certain audience: experts in the fields of software engineering and network protocol design. These are folks with long industry careers or graduate degrees, usually Ph.D.s who have spent decades learning about their field, identifying an untrodden path to pursue advanced research, and eventually becoming so familiar with that path that they are (hopefully) able to learn something that nobody else in the world has revealed before. In the process, they become specialists, because it is only through specialization that a human being can become sufficiently knowledgeable to find what has yet to be known in a field as large as computing. It is only by becoming specialists that we can understand each other when we explain what we have learned, and thereby grow the field of knowledge over time.
James Burke described the problem of specialization in the final episode of his first series on BBC, Connections. If you are having a hard time following my work, then I strongly suggest you go find a copy of the old episodes somewhere and watch them, bearing in mind that it was first broadcast in 1978, when the folks who brought you the Web were at their most impressionable early age. Mr. Burke would appreciate that connection, I think. What he said deserves a bit of transcripting on my part:
The other, general thing to be said about how change comes about through innovation, and especially about the rate in which that change occurs, is that: the easier you can communicate, the faster change happens.
I mean, if you look back at the past, in that light, you’ll see that there was a great surge in invention in the European Middle Ages, as soon as they had reestablished safe communication between their cities, after the so-called dark ages. There was another one, in the sixteenth century, when these [books] gave scientists and engineers the opportunity to share their knowledge with each other, thanks to a German goldsmith called Johannes Gutenberg who’d invented printing back in the 1450s. And then, when that developed out there, telecommunications, oh a hundred-odd years ago, then things really started to move.
It was with that second surge, in the sixteenth century, that we moved into the era of specialization: people writing about technical subjects in a way that only other scientists would understand. And, as their knowledge grew, so did their need for specialist words to describe that knowledge. If there is a gulf today, between the man-in-the-street and the scientists and the technologists who change his world every day, that’s where it comes from.
It was inevitable. Everyday language was inadequate. I mean, you’re a doctor. How do you operate on somebody when the best description of his condition you have is “a funny feeling in the stomach?” The medical profession talks mumbo jumbo because it needs to be exact. Or would you rather be dead?
And that’s only a very obvious example. Trouble is, when I’m being cured of something, I don’t care if I don’t understand. But what happens when I do care? When, say, the people we vote for are making decisions that effect our lives deeply, `cause that is, after all, when we get our say, isn’t it? When we vote? But say the issue relates to a bit of science and technology we don’t understand? Like, how safe is a reactor somebody wants to build? Or, should we make supersonic airplanes? Then, in the absence of knowledge, what is there to appeal to except our emotions? And then the issue becomes “national prestige,” or “good for jobs,” or “defense of our way of life,” or something. And suddenly you’re not voting for the real issue at all.
[James Burke, “Yesterday, Tomorrow and You” (19:02-21:30), 1978]
Still timely after all these years, isn’t it?
As scientists go, I am a generalist: the topics that I care about range from international politics to physics, with most applications of computing somewhere in between. However, when I send out a message to API designers, I expect the audience to be reasonably competent in the field. I have to talk to them as a specialist because I want them to understand, as specialists themselves, exactly what I am trying to convey and not some second-order derivatives. Most of the terms that I use should already be familiar to them (and thus it is a waste of everyone’s time for me to define them). When there is a concern about a particular term, like hypertext, it can be resolved by pointing out the relevant definitions that I use as an expert in the field.
I don’t try to tell them exactly what to do because, quite frankly, I don’t have anywhere near enough knowledge of their specific context to make such a decision. What I can do is tell them what isn’t REST or that doesn’t fit my definitions, because that is something about which I am guaranteed to know more than anyone else on this planet. That’s what happens when you complete a dissertation on a topic.
So, when you find it hard to understand what I have written, please don’t think of it as talking above your head or just too philosophical to be worth your time. I am writing this way because I think the subject deserves a particular form of precision. Instead, take the time to look up the terms. Think of it as an opportunity to learn something new, not because I said so, but because it will do you some personal good to better understand the depth of our field. Not just the details of what I wrote, but the background knowledge implied by all the strange terms that I used to write it.
Others will try to decipher what I have written in ways that are more direct or applicable to some practical concern of today. I probably won’t, because I am too busy grappling with the next topic, preparing for a conference, writing another standard, traveling to some distant place, or just doing the little things that let me feel I have I earned my paycheck. I am in a permanent state of not enough time. Fortunately, there are more than enough people who are specialist enough to understand what I have written (even when they disagree with it) and care enough about the subject to explain it to others in more concrete terms, provide consulting if you really need it, or just hang out and metablog. That’s a good thing, because it helps refine my knowledge of the field as well.
We are communicating really, really fast these days. Don’t pretend that you can keep up with this field while waiting for others to explain it to you.
Dr. Fielding,
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.
Shouldn’t understanding REST be the easy part?
(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.
Dear Dr. Fielding.
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
[…] difficile à comprendre pour le profane. Il a donc posté quelques jours plus tard, le 24 octobre, un autre article dans lequel il explique sa démarche afin de répondre à ces critiques. Pour résumer, il part […]
Is it REST?…
In the last Northeast Roadshow series, we spent a great deal of time discussing what makes a service…
The only nerve you struck with me is that you describe things as REST or not REST rather than less RESTful or more RESTful. Any one fundamental aspect of REST can have a profound positive influence of a distributed application, but not all apps can use every principal all the time.