I recently had an opportunity to attend an event on API/Microservices driven transformation. The speaker was a well-accomplished professional with several years of experience in working with Integration technologies. The speaker went over the advantages of Microservices based design by comparing/contrasting with tightly-coupled designs. The big takeaways are Agility, Scalability, Reusability, and Business view.
Then it was time for Q&A, few questions were on how to implement Microservices, Toolsets etc. but then came the obvious question,
My current SOA based architecture is already Agile, built for Scalability and designed for Reusability from the ground up. What is it that Microservices can bring me?
Speaker’s response was that this is a very much debated topic among Integration professionals and highlighted some differences such as,
Microservices can be containerized for scalability but not SOA services. Microservices are designed with a Business view and not Technical view like SOA services!
Then I saw the audience just nodding their heads in dismay and whispering saying “it’s all the same, it is nothing different”.
My personal view
Fundamentally, the biggest difference between SOA services and API services is the protocol. SOA services were predominantly built on SOAP, while API is developed in plain HTTP under REST principles. This is the elephant in the room that needs to be discussed and rest everything about Microservices/API can be adopted into existing SOA services.
Instead of talking about which protocol is best, let’s take a moment to understand why REST gain popularity.
Death of SOAP Services
Traditionally SOAP services were built for System to System integration, every Software vendor provided framework/utilities to publish and consume a SOAP services that have obscured the complexity of SOAP implementation from the Application Developer. Sometime around the introduction of iPhone in 2007, there was a paradigm shift that was happening on the Front-end applications; the native Mobile Apps and Responsive web Apps can no longer accept an HTML scripted by the server who is not compassionate to the needs of the device. The Apps have taken the responsibility to paint the UI themselves and have relegated the Servers to just shuttle Data.
As an obvious choice, the Backend developers provided the Frontend developers(consumers) the WSDL to the SOAP services to retrieve and update data from Servers. But this did not go well, Frontend developers were not able to easily consume the SOAP services. Two major languages for Front-end applications at the time were Javascript and Objective-C( iOS), both do not have a native support to consume a WSDL or a SOAP client. Developers have to rely on third-party add-ons to consume SOAP services.
The screenshot below from official Apple Developer portal, even in the year 2018 they do not have support to consume a WSDL file automatically. And try google “Javascript SOAP service”, you will see how many questions posted on the Forums and suggestions about third-party frameworks.
This lack of support for consuming the SOAP services on Frontend applications was a big driver for finding something simpler and that is when REST APIs have gained popularity. REST works on basic HTTP protocol, which means you could make a REST call from any device that can make plain HTTP calls without depending on any third party libraries – Browser, NEST thermostat, Raspberry PI or pretty much all devices and applications.
With REST gaining popularity, organizations started sunsetting SOAP services or wrapping SOAP in a REST service, which eventually is leading to the death of SOAP services.
Apart from the protocol simplicity, REST also brings in simplicity to the architecture, but these design aspects can definitely be incorporated into existing SOAP services, and yes even SOAP services can be made stateless for horizontal scaling. Afterall REST was never meant only for HTTP interfaces, it is a general Software Design Paradigm that can be applied to any technology.
Should I convert my SOAP services to REST services?
The decision is for yours to make, but I would like to highlight four trends that you should pay attention to.
1) One Code Base : With REST gaining such a wide adoption and popularity, even Application to Application interfaces which was traditionally a SOAP turf, have started shifting to REST services. This is because REST is simple and second, you can consolidate your integrations by publishing the same services to both Frontend consumer and Application consumer. For example, it will be the same API that will be called when an Order is placed on a smartphone or when the Order is submitted by the Fax service which traditionally was the SOAP service.
2) Look Around : Almost everything around you now is working on REST, major SaaS providers are converting their services to REST, numerous Marketplaces extensions that work on REST services. The future innovations will be focused more on REST services than SOAP services. For example the API Manager.
3) Developer Demographics : The new Developers entering the market come with knowledge on REST services but not much about SOAP, as their academics and labs work mostly are based on REST services. Popular APIs such as Google Maps, Weather, NLP services, almost everything is based on REST APIs. If you are a SaaS provider and you want to entice developers to build extensions on your platform, you may want to choose REST for a larger adoption.
4) The popularity of POSTMAN : 5 million developers, 100,000 companies and 130 million APIs per month – these are stats from POSTMAN App, POSTMAN is the SOAP UI of the API era. The sheer metrics of POSTMAN usage tells how big is the API market and how many organizations are investing in APIs
Conclusion
I have so far not addressed why the blog title says “SOA 2.0”. I have noticed a lot of resistance amongst professionals to API Architecture because it brings no new design features.
I think if API architecture was called SOA 2.0, there would have been a lot of adoption because it would seem like a natural progression(which it actually is) instead of showcasing API as something totally new concept. Just like Web 2.0, Enterprise 2.0, Industry 4.0.
Nice Article!
Thank you for the article. It is clear and concise.
You mention quite valid and practical reasons why you should migrate to REST API and definitely why you would start a new project that is based on REST API. After all, practicality often makes the difference between a successful project and failed one.
However, in principle, REST and SOAP are still both implementations of a SOA architecture. REST is just more practical and cleaner in its implementation than SOAP which is bulky and cumbersome.