Web services in web development
For everyone working on web development, web services are the default cutting tool for almost every need. They’re flexible, easy to develop, and useful in most of use cases. We define a web service as a “frontend interface for a collection of services that provide a certain functionality”. There are 2 grand established types of web services, REST (Representational State Transfer) and SOAP (Simple Object Access Protocol), each one with their own advantages and disadvantages.
Main differences:
The biggest difference between SOAP and REST is the method behind them. REST uses the broadly used URL based HTTP protocol, whereas each URL (or endpoint) exposes a different functionality (ie: a list of objects, create a new object, delete an object). It uses common HTTP methods such as POST, GET, PUT, DELETE, etc. The established HTTP standard also provides intuitive interaction with a REST web service (ie. GET for listing, POST for inserting/creating, PUT for updating, DELETE for removing).
On the other hand, SOAP is based on a specific format of XML, called WSDL (Web Services Description Language) file. A SOAP WSDL file is a public XML that the end-user can access and browse, with all the services it provides and the parameters to use them. Also on the WSDL, there is the result format and sections that the user can expect as a response. This means SOAP establishes a fixed contract on the exact functionality of the entire web service. This also means that SOAP provides a single endpoint for all its services.
Another significant difference is that REST is arguably faster since it lacks the overhead that comes from processing all the SOAP metadata that comes with a WSDL file.
Pros and Cons of SOAP
As mentioned before, SOAP is very structured. The functionality that a SOAP web service offers is stable and the contract it provides means the end user knows exactly how to use it and what to expect from it. This also means that it should be used for static web services that provide a very specific functionality and it allows the necessary stability that another web service or application can use.
Another big advantage is that the XML-based protocol makes it easy to develop and use with programming languages that already make heavy use of XML (such as Java).
Finally, the most common web languages provide native (or broadly used 3rd party) libraries for creating and using WSDL contracts
But not everything is great about SOAP. The established contract works as a double-edged sword in the modern day of web design. A WSDL file is hard to change, and if a SOAP web service needs to be extended, modified or deprecated in some small form, it’s a big change for both the internal developers and the users (who now must adapt to the new contract).
Another big (and related) point is adaptability. A big issue in our daily lives as developers is that our customers expect us to adapt to them, to provide them with the necessary tools to operate as they always do. SOAP is precisely the opposite concept. A WSDL file is a statement of “here’s how we work, you must use this and expect this”. Sometimes it works, more often than not, it is just not what the customer expects. An argument can be made that we can create a SOAP web service for the specific functionality the customer needs, but this means we now have a different product per customer, which in time leads to a circular stairway down to maintainability hell.
Pros and Cons of REST:
REST popularity is on exponential growth. As mentioned before, it provides unparalleled flexibility and scalability in almost any case. When used with an established standard such as RESTFul (for endpoint structure) and HAL (for response), it becomes hard to argue when not to use it.
From a developer standpoint, a REST web service is easy to maintain, to expand and deprecate. There are tools in any web language to automate a web service creation, from scratch. From a customer perspective, it’s easy to consume and its popularity means that it’s more likely for said customer to have the knowledge on how to use it.
On the opposite side, there are several shortcomings. Since it lacks the inherent documentation that a WSDL file provides, a REST web service MUST include a good user manual. Currently, some REST standards try to provide a navigable interface, with links to other related endpoints, but this is not enforced.
Another common problem is security. Since the HTTP protocol is by default insecure, both developer and customer must go out of their way to make every endpoint secure, whether by authentication, web tokens, or HTTPS, a combination of the three or any other measure.
Conclusion:
So what is the correct web service implementation? The answer is “Depends on what does your web service provides”. If you’re aiming for a public web service, with scalability in mind, your choice is clearly REST. If you plan to offer a long-time functionality to an internal corporate service, SOAP has all the advantages.
For anything in between, I strongly recommend a good coffee and a 2-hour long discussion with your team (or the mirror).
