I believe I am in a minority of developers in that I actually have a sweet spot for SOAP based web services. This goes back to when Web 2.0 was very new, and the idea of distributed computing via WebServices rather than RPC was the future.
Being a more traditionally trained computer scientist and object oriented programmer I have always preferred strongly typed programming languages, and web defined Interfaces for services and schema for messaging. The json / REST movement that grew out of Web2.0 was always a bit too anarchic for me at the time. REST API’s with little documentation and no enforced messaging schema or discovery protocols.
Likewise, I was late to the advantages of JSON, preferring XML and XSL for data representation and transformation.
The SOAP based WebServices Stack fitted nicely into my worldview, and the tooling Microsoft provided in Visual Studio at the dawn of the .NET age made it a wonder to work with.
Alas, the world has moved on, but unsurprisingly, lots of data services still use SOAP. One such service is the National Rail API for all things trains in the UK.
I was asked recently to help an existing journey planning interface to integrate with the National Rail Web Service to provide real-time fares lookups. The existing application was all architected around REST/JSON microservices and they wanted a Fare lookup service exposed in the same manner.
This sort of job is an ideal fit for a small Node.js/Express app. With it’s own build it webserver, and efficient multithreaded architecture it makes an idea environment for building such ‘man in the middle’ services.
I created an Express app to provide a REST based web service that tool arguments from the request path, created the relevant SOAP messages, called the National Rail API, extracted the desired information from the results and piped those back to the caller as a JSON object.
No documentation, nor message schema. Just a simple JSON object with the bare minimum information. Just the way the cool kids do it these days.