Representational State Transfer (REST) is an architectural style for creating, maintaining, retrieving, and deleting resources. REST's information-driven, resource-oriented approach to building Web services can both satisfy your software's users and make your life as a developer easier. This article, the first in a four-part series by REST expert Brian Sletten, introduces the concepts that underlie REST, explains the mechanisms that RESTful applications use, and explores the benefits of REST.
The Web has become the mind-boggling global information ecosystem it is not by accident, but because of specific technology choices made along the way. Roy Fielding, originator of the term REST, documented these choices in his acclaimed Ph.D. thesis. He highlighted the goal of building networked software systems exhibiting the properties of:
Performance, as a property, is a quality of responsiveness. Given the networked nature of these software systems, we always want to avoid paying a latency penalty. Scalability is a property that indicates how many users can simultaneously access a service. Generality allows these systems to solve a wide variety of problems. The more moving parts a software system has and the more complex its interactions, the harder it is to prove that it does what it is supposed to do. We would like our systems to be as simple as possible and extensible in the face of new requirements, new technologies, and new use cases.
REST for Java developers
Read the series:
Enterprise-system stakeholders would be hard-pressed to deny that they seek these properties in their operational software. The difficulty comes in mapping them to particular technology choices, such as the choice between REST and SOAP.
Invoking behavior vs. managing information
Although there is room for overlap, SOAP is mostly useful for invoking behavior, while REST is good for managing information. REST can be abused to do SOAPish things, and SOAP can be abused to do RESTful things, but they are fundamentally different technologies. Understanding their differences can lead to appropriate technology choices.
Most applications have traditionally made network requests like the request in Figure 1:
The request is made in a context that can include metadata such as identity, credentials, and preferred response form. The content of the request itself can be kept simple in this model.
SOAP solves the difficult, real problem of making requests that span multiple partners, multiple processing models, and an unpredictable transactional lifetime. In this scenario, a connection cannot stay open for the request's lifetime, so you must decontextualize the request. But once that happens, you need to put the context back into the request. Identity, credentials, security goo, transactional history, and the like accrete around the core request as it moves from receiver to receiver. This model is shown in Figure 2:
This is a legitimate and important use for SOAP. But it does not necessarily represent a direct approach for managing information. When you want to expose data in language- and platform-independent ways, the SOAP interaction style, with all of its moving parts and complexity, is overkill -- and it lacks some of the important features that the REST style offers.
Resistance to REST
If asked, most developers would define REST as "Web services with URLs." That is certainly part of the REST vision but by no means all. One reason why they struggle to understand REST concepts is that going "the REST way" often feels like a rejection of the Web service roadmap presented by the World Wide Web Consortium (W3C) and its industry backers. Uncomfortable with this "deviation" from the norm, they have not fully committed to figuring it out.
Another reason why they struggle is that their focus is on the code they write, not on their customers' needs. Most business users and organizations do not care about the software we write, but rather about information that software helps them get to.
Technical managers too are uncomfortable deviating from the norm. They prefer the alternative technologies -- SOAP, Web Services Definition Language (WSDL), and various orchestration languages -- because they are entrenched in the industry. Real marketing dollars -- manifest in the tons of books, tools, consulting services, Web pages, and blogs that walk you through these technologies' ever-thickening landscape -- are persuasive. These technologies' specifications are impressively heavy. The notion that REST might be a better way to manage information is perhaps less important to managers than the fact that you can't buy REST or sue someone if it breaks.
REST is an architectural style for creating, maintaining, retrieving, and deleting resources. A resource can be anything of potential interest that is serializable in some form -- a file, query, calculation, or concept, for example. This form is called a representation. REST, then, refers to the transfer of some bit of information or application state, as a representation, from a server to a client or back again. The REST approach is not better because it is simply different; nor is it different just because it is simple. It is designed to elicit compelling operational properties by applying a series of deliberate constraints. The REST philosophy echoes Albert Einstein's assertion that "the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." In other words (as Einstein's dictum is often misquoted), "Make things as simple as possible, but no simpler."