SOAP began life as XML-RPC over twenty years ago and is an XML based remote procedure call system that's reasonably common in large, enterprise APIs and was a defacto standard prior to REST and JSON. easy-soap-request is a library that makes it easier to perform SOAP calls from Node, and we caught up with its creator to ask a few questions:

Why did you create easy-soap-request rather than use an existing library?

I was working on a project at a large insurance company and needed to stitch together some legacy APIs for automated testing, but all I could find were implementations in Java. At the time, my team was using Node.js more so I wanted to build this new automation with more modern tech, but what I found is that there isn't really a lot of documentation around using SOAP with modern solutions. The library really took off when I wrote a Medium article explaining how to use SOAP APIs.

There are several existing SOAP clients, but they were difficult to use and the documentation was very verbose. At the end of the day, I just wanted to send a POST request and thought "it shouldn't be this hard".

In what sort of places is SOAP still used?

SOAP really became a thing in the early 2000s, so many companies who have been around since then (especially larger ones) will most likely still have some APIs based on SOAP. Companies in industries such as finance, banking, insurance, government agencies etc. are most likely to still have SOAP-based APIs. Just like how those same companies still have mainframes.

How did you find the process of supporting Node, Deno and the browser all in one library?

That's an interesting question because I never actually intended for that. Each sector of the JS ecosystem has its own convention which helped a lot. The project originally started as a simple Node library so I naturally published it to npm. Then I saw several browser use-cases and integrated webpack into the build process which published the bundle in a dist/ path in the node module.

npm already did the heavy lifting by pushing it to a CDN for me, so the browser library was just accessible via dist/ instead of the root path. Once Deno was inching closer to 1.0, a user opened an issue asking for support. I thought it was a reasonable ask so I figured why not. Deno modules allow you to access modules by any individual file name over HTTPS so I chose index.d.js which I think makes sense.

Most tooling today will allow enough customization for you to solve these types of problems easily, but the trick is to making consumption very clear to the user. That means implementing standarized conventions that developers are already using and good documentation. If you don't have some quick copy/pasta usage in your README, developers are much less likely to use what you've built.