There are two primary messaging architecture models for the web services that underpin cloud computing: SOAP and REST. Each of these has specific benefits and drawbacks, and the decision on which to use in a particular implementation must take a variety of factors into account.
Simple Object Access Protocol (SOAP) is the more formal and traditional model, developed originally by Microsoft in the late 1990s to address legacy and interoperability issues in exchanging information between computers on different networks. Based on HTTP and XML, SOAP is a set of formal standards maintained by the World Wide Web Consortium (W3C) that define rules for addressing an information request and then encoding and delivering the response in a machine-readable format.
REST, or Representational State Transfer, is less of a comprehensive formal standard like SOAP and more of a set of architectural principles for web services. “RESTful” web service APIs, as they’re known, prioritize flexibility and speed compared to SOAP’s reliability and formal structure.
One way to think about the difference between SOAP and REST is to analogize them to two different ways in which a person would go about getting information they desired. For instance, say you wanted a copy of your city’s municipal budget for the upcoming year. In a SOAP-type environment, you would fill out a form requesting that information, mail it to the address of the city’s designated representative, wait for them to process your request and then receive the response on an official form. Thanks to law and regulation, the city would be required to respond to your request, either with the specified information or with an explanation of why it couldn’t provide it.
In a REST-type environment, instead of filling out the form and submitting it to the designated contact, you’d go to the city’s website. Starting at the home page, you’d follow the links that made the most sense until you got to the specific location where the city had posted its budget online. You’d download it and have the information you wanted. But if you had trouble finding the information or it wasn’t available, there would be little to nothing you could do about it.
One major difference between the two models is error handling. SOAP’s error handling goes beyond REST’s use of the standard HTTP response codes (204 NO CONTENT, 404 NOT FOUND, 500 INTERNAL SERVER ERROR, etc.) to provide necessary information for debugging and addressing failures. Instead of a simple “that failed” HTTP response, SOAP error messages must identify the faultactor that caused the request not to be fulfilled, such as “Failed to locate method (DoSomething) in class (ThingsToDo) at /usr/local/Perl/SOAP/example.pm line 1212.” Each of these models has its benefits and drawbacks in speed, reliability and security.
Both REST and SOAP have their own benefits and limitations and each is appropriate for certain types of information exchange. Network architects must balance these factors – as well as more practical concerns such as programming language environments, security and regulatory requirements and legacy data formats – when choosing which to implement in a particular instance.
Are you looking for help in making the choice between REST and SOAP web services for your organization? Contact us today to learn more.
