What is REST? What about SOAP? Why were they created and what are their main features? What makes them different, and when should you use one or the other? We gave an overview of REST vs. SOAP in our recent infographic, but this post delves deeper. Read on for answers to these questions and for an explanation about which use cases lend themselves to a RESTful approach and where SOAP is preferable.

After reading this article, you will know the history of the two important approaches to building Web services that were set forth more than a decade ago. Despite their age, they have not diverged that much from their origins over the years, and they can still coexist to address different needs. You’ll learn that REST was born in the academic world, embracing the philosophy of the open Web, while SOAP was conceived of by large software companies with the goal of addressing the needs of the enterprise market. Finally, you’ll be able to compare both protocols and decide for yourself if you should use REST or SOAP on your next API implementation. Let’s start by looking at REST.

What Exactly Do We Mean by REST?

REST, or “Representational State Transfer”, was created by Roy Fielding in 2000. It was first introduced in his PhD dissertation in which he explores several network-based architectural styles. REST is thoroughly described in Chapter 5 of his dissertation. In this section he states in summary that REST “provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.”

So, REST can be described as a way of building Web services by following a set of specific constraints between consumers and providers:

• Separation of concerns between clients and servers: following this approach, clients should not be concerned about data storage, just as servers should not be concerned about user interfaces. This completely decouples the development of clients and servers, and enables the usage of economies of scale.
• Communication between clients and servers must be stateless: servers should not store any information about the context of clients between calls, with the exception of session information that is used to maintain authentication.
• Clients should be able to cache responses: all server responses should contain enough cache-related information. Clients can then rely on that information, and decide for themselves whether or not it is appropriate to cache responses.
• Connections might occur through several communication layers: clients shouldn’t be able to distinguish if they’re directly connected to the application server or to an intermediary agent that relays the information. This enables the usage of Proxy servers, and several other forms of scalability technology.

REST has often been misinterpreted, and not implemented according to its creator’s original vision. This occurs in some situations mainly because an API is so easy to implement using frameworks. According to Jakob Mattsson, who gave a related presentation at the Nordic APIs Platform Summit, REST itself “is an abstraction of the Web.” Mattsson explains that REST should allow any consumer to interact with the API in the same manner that a person interacts with any Web page — without having prior knowledge of how it works. Consequently, most APIs use only a subset of all REST capabilities, leveraging the simplicity afforded by HTTP’s GET, POST, PUT and DELETE methods in their implementations.

Do You Remember SOAP?

SOAP, or “Simple Object Access Protocol” as it originally stood for, was conceived in 1998 by a group of individuals collaborating with Microsoft. One of those people, Dave Winer, was also the creator of XML-RPC, a “Remote Procedure Call” protocol that uses XML as the standard for message bodies. It was this development that led to the creation of SOAP. Despite having been supported by Microsoft, IBM and others, SOAP was only officially recognized by the W3C in 2003 when they proposed it as a recommendation.

The use of SOAP by Web services conforms to a set of characteristics that make communication between distributed objects possible:

• The protocol is extensible: extensions to the basic functionalities can be built and used without affecting the main characteristics.
• Message content should be independent of the transport mechanism: SOAP can operate not only over HTTP but also on top of other transport protocols such as SMTP. SOAP over SMTP has been used to provide asynchronous communication between clients and servers.
• It should also be decoupled from the underlying programming model: developers should be able to develop SOAP clients or servers without any restriction on the logic or philosophy they follow.

Having enjoyed great popularity during its first years of life, the use of SOAP has been declining over time. SOAP is still used most often in the enterprise world, where communication between different services needs to conform to a set of rules and contracts. Because it follows objects, rules, and constraints, SOAP is a more strict protocol than REST. SOAP usage gained popularity among larger organizations in part because it was a market that Microsoft dominated at the time. The Windows Communication Foundation (WCF), core to developing on Microsoft platforms, still supports SOAP today. Other popular ways of implementing SOAP clients and servers include the PHP Zend Framework and Apache CXF.

Use-cases Where REST is Better than SOAP

While SOAP provides ways of remotely accessing and manipulating objects, REST focuses on the operations that can be executed on resources. In part because of this distinction, REST has gained massive adoption among public APIs practitioners. Also, because REST inherits operations from HTTP, it’s the most obvious choice when deciding how to open a Web API. It has proven so influential that all major Web companies now use and encourage the use of RESTful APIs.

REST is always better than SOAP in situations that do not require you to fully map a set of objects to the client. Communicating object information back and forth can consume a lot of bandwidth, which can be limited in environments where connectivity is expensive. An API consumed mostly by mobile applications is one of the use-cases where you should avoid SOAP at all costs.

Another factor is the simplicity of the REST protocol when compared to SOAP. If you care about how long it takes developers to first interact with your API, REST always wins. What is easier than making an HTTP GET call to a URL and receiving a response in return? JSON even makes things easier by setting a standardized way of serializing and consuming API payloads. JSON’s biggest advantage is its connection with JavaScript and the browser, making the development of API consuming Rich Applications straightforward.

Also, because it is less restrictive than SOAP, supposed REST APIs work better in the open nature of the current Web. Developers are not worried as much about contracts as they are about an API’s ease-of-use. Public APIs change all the time because businesses need to adapt rapidly. In this reality of startups and APIs without specific contractual agreements, REST is a natural choice. Using SOAP in this environment would be counter-productive, as it could introduce unnecessary contractual complexity.

Conclusion

REST and SOAP are from completely different worlds. While REST deals more with operations that can be performed on Web entities, SOAP is focused on how to access and manipulate objects remotely. REST was built upon the foundations of the Web itself by leveraging HTTP’s basic operation (GET, POST, etc.) and this is what it makes it a perfect candidate in any public API implementation. SOAP uses XML and provides a set of features that allow practitioners to define contracts between consumers and providers, something highly valuable in the enterprise world.

Avoid the use of SOAP in those situations where bandwidth is very limited. SOAP needs to communicate information about objects and their states using XML Infoset. Typically, these data models are serialized as textual XML. This, compared to typical REST implementations, consumes significantly more bandwidth. All SOAP’s restrictions that work so well in the enterprise world are counter productive when targeting the open Web. In today’s business climate, which usually does not require the use of strict, long term contracts between clients and servers, such restrictions are not useful at all. Nevertheless, SOAP is still in active use, but just not so much in the public Web APIs.

Are you using SOAP? In what way? Leave a comment here or get in touch to discuss this more!