Every time some Web application service provider comes up with a Web services API that allows developers to integrate with their services, a lot of attention is paid to the interaction design pattern implemented by the API. If the API uses the REST-style interaction, proponents of the REST approach laud the API as a grand example of why REST-style services are far superior to SOAP-style services; likewise if the API uses a SOAP style Web service pattern. Little attention seems to be paid to the fact that the choice of pattern depends largely on the type of application being implemented and, like all good architectural decisions, developers should base their choice on the specific technical needs and characteristics of the application being developed rather than on some particular affinity towards a single architectural approach.
At a fundamental level, the difference between REST-style and SOAP-style Web services hinges on whether or not an application is resource-oriented or activity-oriented.
Resource-oriented services focus on distinct data objects upon which a handful of basic, standard operations can be performed. For developers who are familiar with the concept of object-oriented design patterns, resource-oriented services are akin to the basic Memento pattern, as described by the authoritative Gang of Four (GoF) Design Patterns book. Essentially, a service provider maintains a collection of resources and exposes a collection of basic operations to perform such tasks as:
- Retrieving the resources
- Modifying the resources
- Creating new resources
- Deleting resources
By definition, REST-style Web services are resource-oriented services. You can identify and locate resources by a Universal Resource Identifier (URI), and the operations that might be performed against those resources are defined by the HTTP specification. The core operations include:
- GET - This operation returns a state representation of the identified resource. You can determine the state by a number of contextual factors such as who is submitting the request, the parameters of the operation (passed in as either HTTP headers or query string parameters), and current session state maintained by the service provider.
- POST - This operation performs some form of application-specific update to the identified resource. The behavior of this operation is completely up to the service implementing it. The data returned by this operation is also completely up to the application. It could, for instance, return a state representation, as does the GET operation, or it could choose to not return any data at all beyond the standard and required HTTP response.
- PUT - This operation creates a new resource at an identified location (URI). The operation input must include a state representation of the resource. It is up to the service to create a resource based on that state representation.
- DELETE - The DELETE operation destroys a resource at the identified location (URI).
In many ways, REST-style Web services might be likened to technologies such as SQL, tuple spaces, simple message queues, and so forth. All of which use common simple operations to act against distinct resources.
- SQL - SELECT, INSERT, DELETE, UPDATE, and so forth
- Tuple spaces - GET, PUT
- Message queues - SEND, RECEIVE
In each of these cases, the design of the service interface allows you to move information about resources around, leaving it up to the requester to figure out what it actually wants to do with that information.
On the other side of the coin are activity-oriented services. These types of applications focus on actions that you might perform rather than on the resources upon which they act. A simple example of an activity service would be a bank transaction in which a customer transfers money from one account to another. The customer doesn't want to work with the resources directly (the money, the bank accounts, and so forth), they merely want to tell the bank what it is they want to accomplish and have the bank handle the resources on their behalf. In GoF terms, I'm talking about applications of the:
- Command
- Mediator
- Strategy
- Proxy design patterns
Unlike resource-oriented services, where the operations that might be performed remain relatively constant regardless of the type of resource, operations in activity-oriented services depend entirely on the type of activities being performed. For example, a bank service might expose an operation called transferFunds, whose various inputs would be entirely specific to that service's fund transfer capabilities.
In resource-oriented services, a common set of operations play a supportive role, allowing clients to access and manipulate resources. However, the resource is the center of attention, as shown in Figure 1 below.
Figure 1. Comparing resource-oriented services to activity-oriented services
In activity-oriented services, the operations are the center of attention, with a single operation for each activity the client might request to be performed.
SOAP-style Web services are generally activity-oriented. The WSDL document defines and describes service-specific operations. Operations consist of an exchange of service-specific messages. Each operation is an activity that might be performed. What those operations are being performed against is generally irrelevant. Resources might be implied in the activity, as described by the WS-Resource Framework family of specifications, but such implication is orthogonal to the definition of the activity and serves only to refine the context within which the activity is performed. Contrast this to resource-oriented services in which the activity performed against the resource is orthogonal to the service interface used to access the resource.
Putting it into context: The Bloglines service
Bloglines is a Web-based application service that allows individuals to keep track of their various subscriptions to weblog and news feed content delivered in the form of Really Simple Syndication (RSS) and Atom feeds.
The Bloglines service is fundamentally resource-oriented. Users create, update, and delete subscriptions and access the service on a regular basis to see what updates have occurred since their last access to the site. The Bloglines API appropriately reflects this resource-orientation by making use of a REST-style Web service interface.
Specifically, central to the Bloglines service are a users collection of subscriptions, known generally as a blogroll. A single blogroll might consist of many different subscriptions. A subscription points to either an RSS or an Atom feed.
Blogrolls and subscriptions are both resources. The Bloglines API uses basic HTTP operations to retrieve current status information about a user's blogroll and subscription resources.
For example, to access a current snapshot of a user’s blogroll, the user might send an HTTP GET request to the URI //rpc.bloglines.com/listsubs. In strictly REST terms, this API identifies the subscriptions of every Bloglines user. When invoking the operation, an HTTP authentication request collects additional context about which user's subscriptions to retrieve. The information returned by the operation consists of an XML document listing all of the individual subscriptions for the authenticated user.
To access a current snapshot of a specific subscription, the user might send an HTTP GET request to the URI http://rpc.bloglines.com/getitems?s={subid}, where {subid} is the Bloglines assigned unique subscription identifier as displayed in the results of the listsubs operation described above. Additional parameters might be defined, including (interestingly enough) one that actually violates a fundamental REST rule that GET operations should be idempotent -- that is, that they should not cause any change in the state of the resource. When provided, the parameter (n=1) instructs the Bloglines service to mark previously unread subscription entries as being read, effectively changing the state of the resource.
To return a count of how many unread subscription items are currently in a users blogroll, the user might send an HTTP GET request to the URI http://rpc.bloglines.com/update?user={email}&ver=1, where {email} is the email address of the user whose account should be checked for unread subscription entries.
The only thing the Bloglines API is concerned with is allowing programmatic access to blogrolls and subscription resources. The API does not care what clients do with those blogrolls or subscription once they've accessed them.
To offer a contrast, compare this with a recent proof-of-concept project IBM implemented to illustrate the use of Web services to automate hospital patient records access, prescription writing, operation scheduling, and so forth. Without going into any details (which are covered by a non-disclosure agreement with the client), the primary focus of the collection of service interfaces created for the system focused strictly on activities that users could perform in the system. For example, scheduling a procedure or a test for a patient and requesting asynchronous notification of such events as availability of test results. While patient records (resources) are an important aspect of the system, they generally serve a supporting role in the overall application and are not the central focus of the system. Rather, the hospital prototype is an activity-oriented service, which is accurately reflected by it's SOAP-style Web service architecture.
The point to all of this is simple: the choice of REST versus SOAP comes down to a basic understanding of what is most important to your particular application. If your application is focused primarily on the ability to access informational resources (as is the Bloglines service), then you have a primarily resource-oriented service and should likely turn to the REST-style design pattern for your application. There is significant precedence for this considering the service API's offered by Amazon, del.icio.us, Flickr, Safari and others (see Resources). However, if your application is focused primarily on actions that might be performed orthogonally to the resources upon which they act, then your service is activity-oriented and should likely make use of the SOAP-style design pattern.
Proponents of the REST-based pattern often point to its architectural simplicity compared to the complexities inherent in the broad collection of SOAP-related Web service specifications as being the key to why REST is the superior approach. This argument has flaws in that, as I have illustrated, the two approaches are looking to solve different types of problems. Web-based application services, such as Bloglines, Amazon, flikr, del.icio.us, and so forth, face a different set of issues than say, a hospital looking to automate their internal processes for order procedures and writing prescriptions and therefore demand a different architectural approach. That's why design patterns exist -- different approaches to solve different problems.
Compared outside of the context of specific business requirements, the REST architecture appears far less complex than the SOAP Web services architecture as defined by the myriad of WS-* specifications that have been put forth by the industry. However, it is also far less functional in certain key areas. Reliable messaging is a prime example. HTTP is not a reliable protocol. There are simply no mechanisms built in that allow HTTP requests to be reliably delivered using once-and-only-once or retry-until-success semantics. There are also no mechanisms in REST/HTTP for message routing outside the basic HTTP proxy mechanisms. Security context in REST-style services is also generally limited to the security mechanisms offered by the HTTP protocol unless an application chooses to adopt some externally defined security mechanism (for example, a REST service could actually return a digitally signed or encrypted SOAP message in response to an HTTP GET request).
For services such as Bloglines, these functional limitations are not critical because the basic options provided by HTTP are good enough to suit the needs of their applications. The APIs simply do not need:
- Reliable messaging
- Digital signatures
- Message routing
- Resource life cycle management
- Asynchronous event notification
- Other capabilities introduced by the SOAP WS-* specifications
That does not mean other applications will not require the increased functionality offered by the activity-based approach.
Don't get me wrong, it is entirely possible, at least in theory, to do all of these things in a REST-style service. The key challenge is that nobody has done the work to define consistent and standardized ways of doing so. Until that happens, any approaches that anyone takes in a REST style interface to do things like asynchronous event notification or reliable messaging delivery, for example, will be one-off service specific implementations that will generally not be supported by any other REST-style service. What is more important to point out, however, is that these extended functions are generally more applicable to activity-oriented services than they are to resource-oriented services and therefore it is not surprising that in the realm of activity-oriented SOAP style services we see a far greater number of specifications and an increased level of complexity.
Quick note: complexity is not a bad thing if handled properly. Yes, there are a lot of WS-* specifications, all of which cover a broad variety of technical topics. Taken as a whole, they represent a large degree of perceived complexity. However, the way they are defined embraces the notion of being able to cherry pick only the pieces that are absolutely required to enable an application. No one is expecting every Web service to always implement every WS-* specification.
Bottom line: It's about the services
In the end, it is extremely important that the industry continues to move forward in the direction of Service-Oriented Architectures (SOAs). The choice of REST-style versus SOAP-style should be made with the same care as one would choose between implementing a Command, Mediator, Observer, Strategy, or Visitor design pattern for a given application component. Simply put, it's nothing more than a choice over a design strategy based on business and application need, but it is a choice that can profoundly impact how your application is used and evolves over time. However, more important than the choice of Web service design patterns is the choice to provide Web services at all. Doing so is critical no matter what style of service you choose to implement.
- For more information about the Bloglines Web Service API, see the API documentation site.
- For an example of a Web service that uses both SOAP and REST style interfaces, see the Amazon.com E-Commerce Services site.
- See my developerWorks weblog for more discussion about Emerging Technology topics, including (but not limited to) Web services.
- Amazon, del.icio.us, Flickr, and Safari all have some interesting Web services APIs available for their developers.
- Access Web services knowledge, tools, and skills with Speed-start Web services, which offers the latest Java-based software development tools and middleware from IBM (trial editions), plus online tutorials and articles, and an online technical forum.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
James Snell is a member of the IBM Emerging Technologies Toolkit and has spent the past few years focusing on emerging Web services technologies and standards. He maintains a weblog focused on emerging technologies at http://www.ibm.com/developerworks/blogs/snell. You can reach him at jasnell@us.ibm.com.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags