Q&A: SOAP and REST 101
What are SOAP and REST? What do these Web services have in common and where is each best used? We take a closer look.
SOAP and REST are frequently used acronyms for Web services. What are these technologies, what do they do, how are they similar and different, and what are the best uses for each? For answers, we turned to Elias Terman, director of product marketing at SnapLogic.
Enterprise Strategies: Can you provide some historical context around SOAP and REST?
Elias Terman: The word SOAP started its life as an acronym for Simple Object Access Protocol, but has now come be known as a specific stack of standards and protocols (SOAP, XML, WSDL, etc.) for providing interoperability among distributed applications.
The initial idea behind SOAP was to address the need for a “web of software services” that could be exposed over a network and could be both created and consumed outside of traditional enterprise boundaries. The idea was to use Internet protocols, open formats such as XML and standards to promote interoperability between distributed applications. Sounds pretty basic today, but this was a revelation in 2000. Early backers of SOAP included IBM and Microsoft.
REST stands for REpresentational State Transfer and refers to the architectural style described in Roy Fielding’s 2000 Ph.D. thesis at University of California Irvine. Fielding explained that the World Wide Web could be used as a platform to connect services at a global scale. His work showed that the Web itself is an application platform and that REST provides the guiding principals of how to build distributed applications that scale well, exhibit loose coupling, and compose functionality across service boundaries.
It’s interesting to note that early critics of SOAP complained that it was too simple to provide enterprise-class services. Some critics of REST are making this same argument today.
Which approach is best suited for Web services and why?
Web services are simply a set of standards for realizing service-oriented architecture (SOA). Most people associate SOAP with SOA, but REST is equally suited for Web services, so the specific use case will be the determining factor. The key tenets of SOA are services, interoperability, and loose coupling. REST meets this definition, but its services come in the form of resources. Web services standards initially started with XML, HTTP, WSDL, SOAP, and UDDI but now contain almost 70 standards and profiles developed and maintained by standards bodies such as the World Wide Web Consortium (known as the W3C).
A RESTful Web service is a simpler approach, one that is implemented using HTTP and the principles of REST. It is a collection of resources, with three defined aspects:
- The base URI (Uniform Resource Identifier) for the Web service, such as http://example.com/resources/.
- The Internet media type of the data supported by the Web service. This is often JSON or XML but can be any other valid Internet media type.
- The set of operations supported by the Web service using HTTP methods (e.g., POST, GET, PUT or DELETE).
As described by the W3C, the architecture of the Web is the culmination of thousands of simple, small-scale interactions between agents and resources that use the founding technologies of HTTP and the URI.
How do SOAP and REST handle the transmission of messages and the movement of data?
Although SOAP messages can be transported in a number of ways, they are sent almost exclusively using HTTP (or HTTPS). REST uses HTTP (and HTTPS) as transport exclusively.
With SOAP Web services, XML is used to tag the data, SOAP is the standardized XML layout used to transfer the data, and WSDL is used for describing the structure of the services. SOAP’s XML-based messaging framework consists of three parts: an envelope that defines what is in the message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing procedure calls and responses.
REST uses simple HTTP to exchange messages between machines. RESTful applications use HTTP requests to post, read, and delete data. REST’s uniform interface is considered fundamental to the design of any REST service. With REST, all resources are identified using URIs and the resources themselves are represented using HTML, XML, JSON and other common formats.
What are some of the primary differences between SOAP and REST?
REST allows for different data formats (such as JSON, ATOM and others) whereas SOAP is limited to XML. Unlike SOAP, REST reads can be cached which improves performance and scalability over the Internet.
REST is limited to HTTP-based security, which can’t provide a two-phase commit across distributed transactional applications, but SOAP can. Internet apps generally don’t need this level of transactional reliability, but enterprise apps sometimes do. Similarly, REST doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has more controls around retry logic and thus can provide more end-to-end reliability and service guarantees.
SOAP achieves loose coupling through middleware (e.g., an Enterprise Service Bus) whereas REST is innately loosely coupled. Coupling is simply the amount of dependency between two hardware or software elements or systems. With SOAP and tight coupling, elements are more tightly bound to one another so that when one element changes other elements are impacted. Loose coupling reduces dependencies between elements or uses compensating transactions to maintain consistency.
A Web site is a great example of a loosely coupled set of elements. If one of the pages is not available, you get a 404 Not Found Page for that particular page. As an extreme example, if that particular page were very tightly coupled with the rest of the Web site, the entire site would go down.
Where is SOAP best deployed? Where is REST best used? Can they co-exist?
SOAP is best for mission-critical applications that live behind the firewall while REST is made for the cloud. SOAP is all about servers talking to servers, with rigid standards, extensive design, serious programming, and heavyweight infrastructure all essential parts of the equation.
As you might expect, then, SOAP does a better job of maintaining consistency in complex environments through the use of techniques such as a two-phase commit. For example, wiring money to a bank account. Did the transaction fail? It’s probably a bad idea to continue to automatically wire the money over and over again, so SOAP might make more sense if you're orchestrating a set of complex services to effect a transaction -- no transaction takes place unless each and every distributed service succeeds.
If you’re interested in building your applications quickly and with maximum portability -- especially if the Cloud (public, private, or hybrid) is in the picture -- it’s hard to beat REST. It sports a mere handful of simple HTTP API commands, and every object (known as a ‘resource’) has its own unique Uniform Resource Identifier that provides a path and distinct name.
REST’s straightforward API and clear, consistent labeling philosophy is far more developer-friendly than SOAP, which mandates deep understanding of site-specific APIs. REST lets you publish your data and have others -- regardless of where they might be – work with it. Just looking at the URI gives you an indication of how to proceed. Today, REST is clearly winning out when it comes to API protocols.
SOAP and REST can coexist in that you can build your service logic once and then expose two interfaces for it: SOAP for inside the firewall (including all its related qualify-of-service capabilities) and REST for outside the firewall.
When it comes to meeting integration requirements in the cloud, which approach provides the most flexibility and extensibility and why?
REST wins when it comes to integration requirements involving the cloud. REST’s sweet spot is exposing a public API over the Internet to handle CRUD (create, read, update, and delete) operations on data. REST is focused on accessing named resources through a uniform interface. Uniform interfaces are innately better when it comes to integration. Don’t take my word for it. The Internet itself has already weighed in on this one. Programmable Web shows that a whopping 73 percent of APIs registered on their site are REST-based while only 16 percent offer SOAP.
Perhaps most importantly, if you need to get something up-and-running quickly, with good performance and low overhead, REST beats SOAP, and isn’t that what cloud computing is all about?