Roy Fielding's dissertation "Architectural Styles and the Design of Network-based Software Architectures" is one of the most often referenced (but not-so-often read) technical papers concerning software in recent years. Saying the content in the paper is influential is an understatement, because it is the underlying motivation for the HTTP protocol and the web itself. The one thing I have not seen while perusing books or blogs about RESTful services is a break down of the actual dissertation. I've therefore decided to focus some time on re-reading the paper while making mind maps to help me improve my understanding of it.
My goal is to dissect the whole paper, not just the parts about REST, in a way understandable to programmers with about 5 years of experience. One thing that stands out in the paper is that it's mostly about architecture. This is interesting to me because I have rarely seen this talked about in the REST blogs. There could very well be something we are missing in the paper that would help shed light on the why and when (to use) of REST.
At a high level, Roy Fielding surveys the state of the art in software architecture. He then gives his take on a way to define a custom architecture for your specific problem domain. Within architecture, he gives a definition for components, or rather architecture pieces (elements) that are made up of the triad of components, connectors, and data elements. This is noteworthy because of the confusion in the enterprise world on just what a component is. He then talks about the special needs of a network application. Most IT professionals are familiar with networks, or applications, but not both. The paper stresses that this dichotomy promotes creating applications that don't utilize the network properly. The network and web requirements are used as the context to present the REST architecture in the latter half of the paper. After that is a history of REST, the history of the development of HTTP, and the application of REST to HTTP.
I hope to drill down through each of these pieces as I explore the paper itself. In my next post I review the architecture methodology discussed in the paper. Hopefully this will help guide my discussion of REST architectures in the future.
This article was originally published on wwatson.net