An architectural style is an abstract formulation of the common properties of similar architectures. For example, UNIX shell programs and many compilers follow a pipe-and-filter approach. What is different about these programs is the exact nature and capabilities of the filters. However, there are some commonalities. One is that every filter has a consistent interface and is independent of other filters. An architectural style expresses these commonalities.

To express an architectural style, one needs a common language for architectural elements. Perry/Wolf [PW] define three types of elements: processing elements (components), data elements and connectors. Components process data elements passed to them via connectors. In the pipe-and-filter style, filters are components, the data passed between filters is the data element and pipes are connectors.

The client/server style is very popular with designers of distributed applications such as web services. The client/server style includes two components: clients and servers. A server component offers particular functionality, while a client component makes requests of the server component. Client and server connectors handle the passing of requests and responses from clients to servers. In doing so, the connectors form the interface between the client and server components. The request and response data provided by the client and server components to the connectors form the data elements of the client/server style.

Many different types of connectors have been employed in client/server systems. One of the most prevalent is the RPC connector. This connector allows the server to expose functionality as a set of named procedures or services, with specific input and output parameters. A client connector's interface to a client component will include these same procedures and parameters. When the client component invokes a procedure on this interface, the client connector will handle making the actual request by communicating the procedure invocation over the network to a server connector. In turn, the RPC server connector invokes the matching procedure deployed within the server component. One can see from this how a connector defines the interface between components.

In most cases, to facilitate client-to-server RPC communication, a client connector must be configured to communicate with a specific server connector prior to procedure invocation. Several schemes exist to perform such configuration. For example, one may need to explicitly set the network address of the desired server connector prior to invocation. Alternatively, one may specify a name or label for the server connector. The client connector will then use that name to obtain an address, possibly with help from some distributed naming service.

The major benefit offered by the client/server style is the separation of functionality between client and server components. This allows each component to be simpler, as each only has to focus on a particular function. Additionally, it provides for reuse of server functionality across client components.

What is a web service? There are myriad answers to this question, meaning there are many definitions of a web service. This paper adopts a fairly high-level and abstract definition (in a relative sense), in keeping with the focus on architectural style as an abstraction of concrete architecture. A web service is basically some functionality offered to external applications, primarily so they can obtain or manipulate information. What makes a web service different from other distributed application-to-application mechanisms such as CORBA, DCOM and RMI is that it is based on Web standards for data formats and application protocols. This allows distinct applications, either within an organization or outside an organization, to interoperate more freely. The most common standards utilized are [XML] for data format and Hypertext Transfer Protocol (HTTP)[HTTP] for application protocol. The fact that there are many implementations of XML and HTTP increase the ease with which a web service solution may be implemented. That is, in most cases, an organization will already have an HTTP infrastructure in place, and can readily obtain an XML processor in almost any language.

In most cases, web services are about exposing existing functionality using web standards. It is about re-purposing what already exists in a different form to get more financial "mileage" out of existing "assets". Organizations have HTTP servers, so they use HTTP for web services. Organizations that extend this philosophy to account for the full range of the massive existing HTTP infrastructure on the Web will receive additional benefits.

Web services are also characterized by the distance, along two dimensions, between users of the functionality and providers of the functionality. One dimension is network distance - the real promise of web services is in the integration of distinct applications over a widely distributed network, the Internet. Many components of the Internet are out of either party's control, and thus one cannot directly influence and control their reliability. The longer distance stresses overall performance as well. The Internet is not equivalent to a 100 megabit internal Ethernet LAN, either in speed or in reliability.

The other dimension is organizational distance. Web services are partly about connecting independent parties rapidly. The key word here is independent. One party cannot completely influence the other, and web service providers may not know all the consumers of their services. In such an environment, "all-at-once" coordination between all parties involved with a web service is very difficult to achieve. For example, a web service provider cannot expect to be able to alter the service interface and have all the consumers simply follow suit.

Implementors of web services exposed over the Internet should also expect a larger population of consumers than services exposed only within an organization. In fact, as the web services model matures and adoption increases, implementors should expect consumer (and therefore transaction) volume to reach or exceed typical web site volume. This adds scalability concerns and exacerbates the performance and interface evolution concerns. Exposure over the Internet presents additional obvious security considerations. This applies to the transport-level (firewalls) and to application level concerns such as authentication and authorization.

The majority of web services efforts to date employ a basic client/server style, using an RPC connector, but further constrained in three important ways. First, data elements (request and response data) must be XML documents. Second, the web services RPC connector is constrained to utilize Simple Object Access Protocol (SOAP)[SOAP] messages between client and server connectors. Third, the RPC connector must abstract the underlying transport protocol to the component.

The XML constraint on data elements imparts several important properties. First, it allows further independence between client and server components, because XML is an implementation-independent format. This is in contrast to other formats that encode data in language-specific ways. For example, a Java object serialized using Java language serialization will be completely unusable in a C++ environment. Second, XML document may be processed in a stream-oriented fashion, allowing components and connectors to process requests and responses incrementally. Third, XML processors are readily available in many languages, which should ease implementation.

SOAP messaging provides several important features in an RPC environment. SOAP defines a standard XML message structure, allowing different connector implementations to communicate effectively. Within this structure, SOAP also defines a standard RPC protocol, further enhancing connector interoperability. Finally, SOAP defines a standard error representation, called a fault. Taken together, these features allow for the development of many alternative connectors, which can be selected independently by clients and servers without losing interoperability.

Perhaps more interesting is the RPC connector's hiding of the underlying transport protocol. A connector may be capable of using several different protocols to transport the SOAP message from client to server and vice-versa. The most common protocol employed is HTTP, but others such as Simple Mail Transport Protocol (SMTP) may be used. HTTP-based RPC web services commonly establish a single HTTP "service endpoint" that will receive procedure invocation messages via an HTTP POST. Regardless of the transport utilized, the connector presents the same interface to the component. As with the overall client/server style, this constraint offers separation of concerns between a component and a connector, allowing each to evolve independently.

The various SOAP toolkits ^[1] provide concrete examples of RPC web services client and server connectors. When using these toolkits, client-to-server communication functions much like basic RPC as described in Section 1. A web services client will invoke a "client-side version" of the procedure made available by a remote server. On the server, the RPC web services connector receives the request, likely from another connector that handles the underlying transport protocol. The RPC web services server connector examines the procedure invocation message, invokes the corresponding procedure, and sends back the response.

While the REST style [REST] has received much attention lately in web services discussion groups and standards bodies, its basic principles have been with us for some time. In fact, the REST style is a distillation of the modern Web architecture to its core concepts, formed in order to analyze future modifications to the Web against these core concepts. Like the RPC web services style, REST is based on the client/server style. However, REST applies numerous constraints to architectural elements, allowing a resulting architecture to exhibit properties not found in a traditional client/server style using an RPC connector. These properties are important to fulfilling the requirements of a large distributed system like the Web.

REST places a high degree of importance on data elements, and specifically a data element called a resource. A resource is nothing more than a set of semantics, a concept. For example, "today's movie schedule for my local movie theater" could be a resource. Note that a resource is not an implementation of its semantics, or a means by which one may obtain information, or the storage mechanism for information - it is just a concept. It is also important to note that while a resource, and therefore the associated semantics, does not change over time, the resource's state will. In the preceding example, the actual movie schedule will vary from day to day, but it will always be today's schedule.

REST defines two additional data elements that allow components to deal with resources: resource identifiers and representations. A resource identifier serves one and only one purpose - it provides an unambiguous label (i.e. identifier) for a resource. A resource identifier is unambiguous in the sense that a single resource identifier labels one and only one resource. It is possible, however, for a single resource to be labeled with many different resource identifiers. It is important to note that a resource identifier only labels a resource - it is not an address for interacting with resource, but it may be used in such a fashion. A representation is the state of a resource captured at a particular instant in time. It may contain raw representation data and metadata such as the format of the raw representation data. In the modern Web, Uniform Resource Identifiers (JAX-RPC)[URI] are resource identifiers, and HTML documents, PNG images and XML documents are examples of representations.

A REST application functions by transferring representations between components using a connector. REST components include user agents and origin servers. These are analogous to the client and server components of the RPC web services style. Origin servers are responsible for implementing resource semantics - that is providing and consuming representations according to the semantics identified by a resource identifier. User agent components interact with origin servers (through connectors, naturally) to obtain representations and send revised representations to the server. Mozilla (http://www.mozilla.org) and cURL (http://curl.haxx.se/) are examples of user agents in the modern Web; Apache (http://www.apache.org) and Jigsaw (http://www.w3.org/Jigsaw/) provide examples of origin servers.

REST client and server connectors are critical elements of the REST style. They are constrained to be uniform, abstract and stateless. The uniformity constraint ensures that clients interact with each and every server component using a consistent interface. In RPC terms, this means that each and every server exposes the exact same procedures with the exact same semantics and the exact same parameters. Given that a REST interaction involves only a simple transfer of representations, one can see how a consistent interface can be achieved - there are just not that many possible operations that are needed to perform a simple transfer. Like the connector of the RPC web services style, a REST connector is abstract, hiding the underlying communication protocol from the component utilizing the connector and therefore separating concerns between the component and the connector. REST connectors also ensure that all interactions are stateless, with each request and response carrying all information necessary to fully understand the request or response independent of any preceding interaction.

A REST client connector allows a component to identify a target resource (through a resource identifier) and transfer a representation from or to an origin server responsible for that resource. A server connector receives requests for representation transfer and allows for propagation of responses to those requests. Various libraries such as libwww (http://www.w3.org/Library/), libcurl (http://curl.haxx.se/), and Java's java.net (http://java.sun.com) package are examples of a REST client connector. Server-side libraries such as libwww and the Java servlet API (http://java.sun.com) exemplify the REST server connector. It should come as no surprise that all these concrete connectors can employ the HTTP protocol for transfer, as HTTP is specifically engineered for transfer operations and is a critical piece of the modern Web. However, it is important to note that a REST connector is not constrained to use only HTTP - it may use any protocol it wishes so long as the interface remains uniform, abstract and stateless.

A REST client or server connector uses a resource identifier in a similar fashion - as an indirect means of identifying handlers for different parts of the interaction. A client connector will use the resource identifier to locate an appropriate handler to make the request and process the response. For example, Java's java.net package allows for the lookup of a handler based on the scheme of the URI. The key point here is that the REST client component does not specify the handler, it specifies the resource identifier which is then used to determine the handler. A REST server connector goes through a similar process, using the resource identifier to locate a handler to fulfill the request.

The REST style also requires server connectors to indicate the cacheability of responses to representation transfer requests. In the modern Web, this is accomplished by the caching mechanisms built into HTTP. REST defines a specific type of connector, called a cache connector, which can examine the cache control data on a response and save the response for future use as appropriate. A cache connector can be applied to a client connector (e.g. a web browser cache), allowing one to avoid making a distributed request if the response can be fulfilled from the cache. The same process can be applied to a server connector to avoid the generation of a response from scratch. REST also defines specialized components called a gateways and proxies that can intercept requests to an origin server. A gateway or proxy is both a client and a server, and contains both client and server connectors. A cache connector may be applied to gateway or proxy server connector to form what is commonly called a cache server. Squid (http://www.squid-cache.org/) provides a cache server example for the modern Web. To the extent that responses can be cached, and cache connectors can be applied, REST's cache constraints can improve an application's scalability and performance.

A web service architecture in the REST style will commonly apply two additional constraints. First, resource representations will be in XML format to derive the benefits of XML as described in Section 3. Second, REST connectors will utilize the HTTP protocol, since HTTP is quite prevalent on the modern Web and helps meet the REST connector's uniformity and statelessness constraints.

This section compares the RPC and REST styles for web services by examining specific properties or quality attributes in isolation. The strength or weakness of either style with respect to a given property should be viewed relative to the importance of that property in a given situation. For example, style A may be more scalable than style B, but this is of minimal consequence if scalability is not a concern for the system under construction. The following properties are discussed in this section:

It is also important to realize that the subsequent analysis is based on constraints imposed by the architectural styles and on common implementation patterns, not on a specific implementation. A specific implementation may or may not meet all constraints of its style, and may not employ a common implementation pattern. Additionally, there are concerns not specifically addressed by an architectural style that can affect a system's properties. For example, no architectural style is going to prevent a programmer from writing a slow algorithm, thereby decreasing performance. Consequently, one cannot apply the subsequent analysis unilaterally - one must first examine how well a given system adheres to its style, and then act accordingly.

Scalability pertains to a web service's ability to handle increases in activity without performance degradation. REST's stateless interactions and cache constraints positively affect a REST-styled application's ability to scale. Stateless interactions prevent a server connector from tracking requests associated with a specific client connector over a period of time (session). In a highly distributed application with an unknown, uncontrollable and potentially large number of clients, allowing for tracking client requests can easily lead to scalability issues. A REST application avoids these issues by forbidding the practice altogether. RPC web services can be stateless as well, but they can also be stateful. In fact, Java API for XML-based RPC (JAX-RPC)[JAXRPC], a standard Java API for RPC web service client and server connectors, specifically requires such connectors to support stateful interactions.

As mentioned in Section 4, REST enables responses to be cached and subsequently served from a cache. This improves scalability by indirectly reducing the number of requests that will require processing by an origin server, which is usually the most resource-intensive processing in the application. By placing cache servers close to the point of request origin, one can also reduce the number of requests transmitted over a wide-area network such as the Internet, thereby improving the scalability of network machinery such as routers and firewalls.

One might think that since RPC web services commonly employ HTTP, and HTTP includes REST-friendly caching mechanisms, that RPC web services can enjoy these caching benefits as well. Unfortunately, that is not the case because the RPC web service style utilizes HTTP as a transport protocol, and not as an application protocol. HTTP's caching mechanisms rely on accuracy in a) the use of HTTP methods to reflect application semantics and b) the allocation of distinct URI to distinct information resources. RPC-styled web services fail to achieve such accuracy because they a) use POST for both modification and retrieval requests and b) allocate a single URI to disparate resources. Consequently, RPC web services cannot utilize the caching mechanisms of HTTP and therefore cannot enjoy the resultant benefits. On the contrary, REST web services use HTTP as an application protocol and correctly allocate distinct URI to distinct information resources. Therefore they can enjoy the benefits of HTTP caching.

Performance pertains to the speed, both actual and perceived, of a given web service. REST's stateless interactions can actually hamper performance by requiring all necessary information to be transferred between components. Depending on the nature of the application, this may or may not be a significant issue. REST web services may compensate for the additional information transmitted by employing caching to eliminate the need to transmit information in the first place. RPC web services can be stateful, and therefore can reduce the amount of information transferred between components by maintaining state at the server and transmitting only state "identifiers". However, web service implementors must balance this performance advantage with the scalability downside and other negative properties associated with stateful interactions.

Flexibility is the ability of a web service to be implemented and consumed in different ways. The numerous constraints of the REST style, especially on connector behavior, reduce the universe of readily available implementation choices, thereby reducing implementation flexibility. To build a web service in the REST style one needs a protocol capable of supporting a uniform interface, and there is really only one available choice: HTTP. One could, for example, build a REST web service using SMTP, but one would need to define a set of operations with application semantics. On the contrary, RPC web service connectors only need the protocol for transport purposes because the procedures carry application semantics. Any protocol is capable of transport of some sort, so RPC web service implementors have numerous readily-available options.

On the service consumption front, REST web services excel in flexibility. In particular, REST web services that perform information retrieval (i.e. HTTP GET operations) are readily and immediately consumable from an enormous number of environments. Some environments in which a REST web service can be readily consumed are:

Implementability refers to the ease with which one can produce or consume a web service. Perhaps more than any other, this property highlights the extensive differences between the RPC and REST styles for web services. There are several factors that contribute to implementability; each will be examined in turn.

Interface complexity contributes to web service implementability. As the complexity increases, production costs associated with design and development increase. The costs of consuming the web service also increase, as consumers must spend more time understanding a complex interface. The number of operations, and their associated semantics, drive interface complexity. The RPC web services style does not constrain the number and semantics of operations. Consequently, the associated complexity is unbounded. This is especially true from the view of the consumer. In an RPC web service model, a consumer should anticipate needing to digest a different set of operations for each web service consumed.

On the contrary, REST constrains the number and semantics of operations. Every REST web service exposes one or more operations from a uniform set of operations. So, there will be variability across services, but that variability will be less than the RPC web services case because operations must be drawn from a uniform set of operations. It stands to reason that a REST web service will present a substantially less complex interface than an equally-functional RPC web service.

The availability of development tools also contributes to web service implementability. As mentioned in Section 2, web services commonly expose existing functionality through a more universally accessible interface based on Web standards. There are numerous tools available that can take existing RPC-oriented functionality and "automatically" make it available as an RPC web service. Additionally, these tools generate the corresponding client connectors. These tools can dramatically increase the speed at which one can produce and consume RPC web services. Such tools are not readily available for REST web services.

Exposure to the architectural style also plays a role in web service implementability. Web services that "feel" familiar will be easier to produce and consume. The RPC web services style will obviously be quite familiar to web service producers and consumers, as it is the basis for most existing web services, and it is simply a refinement of a very common distributed system style. REST should also be familiar to most, as it reflects the properties and interactions associated with the Web. However, the use of the REST style outside of "web browsing" is not familiar to most. This reduces the implementability of a REST web service.

As can be expected, existing web services employ either the RPC or REST style. Differences between the two styles may be highlighted by devising an alternative REST-styled implementation of an RPC-style web service and vice-versa. This section provides several such comparative counter-formulations.