When I was reading about REST APIs, the acronym SOAP kept coming up. In this blog post, I wanted to learn more about what SOAP means and how it compares to what I’ve already learned about REST. The article that I am pulling information from, https://smartbear.com/blog/test-and-monitor/understanding-soap-and-rest-basics/, is a thorough resource, detailing features of each service and how each can be considered “better” than the other.
SOAP (Simple Object Access Protocol) uses XML, a language like HTML, to send requests to a server and receive responses. SOAP was designed to be extensible, with multiple acronyms coming with it to support different usages of the services, such as “WS-Security” or “WS-Coordination.” However, when using free, public web services, these extensions may not be necessary to come into play; it is simply convenient to provide extra functions if needed.
One potentially problematic feature of using SOAP has to do with the entry of XML for requests. Because the complexity of XML code to make requests, some programming languages have built-in support to handle such requests. However, some are not as forgiving and require manual building of the XML code. While SOAP has error handling (which helps to identify where the request went wrong, as well as potentially automate fixing such errors using standardized codes), it is still intolerant to errors caused from incorrectly building the XML. REST has more of an advantage here, because of its reduced difficulty when creating requests; instead of having to program an entire XML file (depending on whichever language you use), REST just uses requests through the URL. This results in faster performance with REST.
With this in mind, though, SOAP does provide other advantages. Coming with built-in error handling is certainly a leg up from REST, along with flexibility of services with other extensions that have different functions. While REST focuses more on quick performance and a lack of complexity, SOAP increases functionality and handles errors effectively.
It is also important to note that unless a developer is making their own Web service, most free and public Web services make it clear which access protocol they use, whether it is SOAP or REST. Even if the Web Service that I access for my final project already has a defined access protocol (which is REST), I am glad to understand more about other options out there for different services available.