What is REST?
Recently we studied how to write RESTful applications. I got that it has something to do with naming paths for resources, but what IS REST? What is all this buzz about? I go to the definition and it says: REpresentational State Transfer.
Looked like random words to me. I go to Wiki and read “Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services (RWS), provide interoperability between computer systems on the Internet. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations. Other kinds of Web services, such as SOAP Web services, expose their own arbitrary sets of operations.”
Still not clear. What constraints? Where did they come from? What is not REST if the goal of all Web services is to allow systems to access and manipulate Web resources? Aren’t they all REST then?
So, to make it more clear for myself, I went straight to the origin, Roy Fielding’s dissertation, and here is a little summary of what I read.
Wait, whose dissertation? This guy:
He was the first to define REST as a key architectural principle of the World Wide Web in his doctoral dissertation Architectural Styles and the Design of Network-based Software Architectures in 2000 at the University of California. Fielding has also been heavily involved in the development of HTML and Uniform Resource Identifiers. No wonder that REST became an Internet standard (70% of modern web applications are RESTful) — REST was invented with HTTP and URI in mind and vice versa.
In the mid-90s, when the Internet started to grow immensely, along with pressure from the industry to standardize Web protocols, the World Wide Web Consortium (W3C) was formed to define HTTP, URI and HTML. Fielding was one of the first invited. A bunch of smart guys worked hard to figure out how to make Internet performance higher, more effective, more scalable and simple, and how to make its components more modifiable, visible, portable and reliable.
Ok, enough history, what did he write in his work and what are all these constraints about?
He starts with a definition of software architecture as a combination of elements — components, connectors and data — combined together in a way to achieve the desired properties of the system. Components transform data or information, and connectors are mechanisms that transfer data between components. The configuration of these elements is their structure and relationships. A style is a set of constraints that restricts the roles/features of elements and allows relationships among them.
So, REST is a style, like a writing style, not a protocol, and will work any way you write it, in any format and language.
Then he analyzes more than 20 different major architectural styles and their impact on the desired features of the network functionality mentioned above. Looks scary:
Then he defines REST as a hybrid style derived from several existing styles with some additional constraints that define a uniform connector interface.
He starts with the Null style, where there are no distinguished boundaries between components. Then he adds the first constraint, client-server (as opposed to peer-to-peer architecture). The main idea is to separate user interface concerns from data storage concerns. This constraint improves user portability and simplifies server components, thus improving scalability. Plus, components can evolve separately.
Then he adds another constraint: communications should be stateless, i.e., each request from client to server should contain all necessary information. This feature improves visibility and reliability since we don’t have to analyze more than just one request. Scalability is improved since a server doesn’t spend extra resources to keep sessions, as all session states are kept by the client. You may ask, what about all these cookies everybody uses? Well, according to Fielding, cookies are violating REST, since they bring confusion and danger to security and privacy.
The next constraint, cache, improves productivity, so data should be labeled if it’s cacheable or not.
So far we’ve described early Web architecture, the client-cache-stateless-server combination. The next three constraints added by the consortium form the modern Web architecture.
Uniform Interface is the central feature of REST. Implementations are decoupled from the services they provide, which encourages independent evolvability. In REST, this leads to four interface constraints: identification of resources, manipulation of resources through representations, self-descriptive messages, and hypermedia as the engine of application state.
The key abstraction of information in REST is a resource. Any information that can be named can be a resource. REST uses a resource identifier to identify the particular resource involved in an interaction between components. REST connectors provide a generic interface for accessing and manipulating the value set of a resource, regardless of how the membership function is defined or the type of software that is handling the request.
The state of a resource at any particular timestamp is known as a resource representation. A representation consists of data, metadata describing the data and hypermedia links which can help clients transition to the next desired state.
The data format of a representation is known as a media type. The media type identifies a specification that defines how a representation is to be processed (think MIME). A truly RESTful API looks like hypertext. Every addressable unit of information carries an address, either explicitly (e.g., link and id attributes) or implicitly (e.g., derived from the media type definition and representation structure).
By the way, nowhere in his dissertation does Fielding speak about what GET/POST/PUT/DELETE methods are supposed to do. All he emphasizes is that the interface should be uniform.
The next feature, layered system, means adding independent intermediaries like proxies, firewalls and gateways between the client and server. This definitely improves security, simplicity and scalability, as opposed to building these filters inside components which would reduce component independence and add complexity.
The final addition and the only optional constraint is the code-on-demand style. REST applications can use applets and scripts, thus increasing functionality.
So, that’s basically what the REST style is. In the last chapter of his work, Fielding describes his experience and lessons learned from applying REST architecture in the modern WWW.
Fielding emphasizes that REST was invented specifically for Web-applications and distributed hypermedia. It is not a magic pill for any type of web-application. There are other styles that may be more reliable, secure and appropriate for your particular application. For example, people often contrast SOAP with REST (though comparing a protocol and a style is kind of weird). Maybe later I’ll make a post about REST alternatives as well.
