REST: Another Way of Looking at Web Services
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Using Web services today means using SOAP. Although some might argue that it's possible to create Web services without this standard protocol, the truth is that there's no way around it. SOAP has become the sine qua non of this new technology.
But is the approach taken by SOAP the only way to create Web services? It's not, of course. Many paths exist to a destination, and the goal of Web services can be arrived at in diverse ways. SOAP's designers came from an entirely valid perspective—one that was rooted in remote procedure call (RPC) technology. Although SOAP can also be used in an asynchronous style, it evolved from an earlier protocol called XML-RPC, and the initial SOAP specification explicitly defined an RPC-style mapping of SOAP to HTTP. SOAP clearly grows out of this earlier tradition in distributed computing.
An Alternative View
More recently, a quite different approach to Web services has appeared. The brainchild of Roy Fielding, it's called Representational State Transfer (REST). Rather than growing out of the RPC world, its roots are solidly embedded in the Web itself.
To understand REST, it's useful to start by summarizing the key aspects of the usual SOAP approach. In the SOAP world, each endpoint has a URI, such as http://www.qwickbank.com, and each endpoint exposes various methods. Any of these can be invoked via an HTTP POST, with the specific SOAP method being called identified within a SOAP envelope that gets embedded in the POST request. Each data object that's accessed is identified using some parameter value, such as a character string. To read the balance of a savings account maintained by QwickBank, for example, a client might invoke a GetBalance method at http://www.qwickbank.com—identifying a particular account by passing its account number as a parameter.
This makes perfect sense, right? If, like me, you come from a traditional RPC-style background, the SOAP approach is the obvious way to expose methods on the Web.
But it's not the only way. What if we instead take a more strictly Web-oriented approach? This is what REST does, and the result—exposing methods using Web technologies—is much the same. The way those methods are exposed, however, is quite different. For instance, rather than assigning each endpoint a URI, the REST approach argues that each data item should have a URI. Instead of a single endpoint for QwickBank, say, why not expose a distinct URI for each account the bank maintains? This is much more like the Web today, in which each item (for example, each page) that a client wishes to access can be directly named.
And rather than hiding arbitrary method names inside a generic HTTP POST request, why not use the HTTP methods that already exist? These methods—such as PUT, GET, POST, and DELETE—can be used to create, read, update, and delete information. These four operations, sometimes referred to with the inelegant acronym CRUD, are the fundamental things we need to do to data. Why not use them directly? Firewalls, for example, could then filter based on HTTP method names rather than performing the complex (and perhaps impossible) task of deciphering each SOAP packet to filter requests on a per-method basis.
Similarly, rather than identifying parameters using character strings and other values opaquely embedded in a SOAP packet, why not use URIs? Identifying everything—everything—with a URI is fundamental to how the Web works. Among other things, a common naming scheme allows easier composition of independently developed software, which is a core goal of Web services. In the REST model, requesting the balance of an account maintained by QwickBank could be as simple as sending an HTTP GET to the account's URI. Rather than building a distinct infrastructure on top of the Web, REST uses what the Web provides to create a simpler and perhaps more effective means to the end of Web services.