I'm working with a very well-known American company with over $4b annual revenue that shall remain nameless and is currently developing a new SOAP API to replace the existing "dump a CSV on an FTP server" integration.
fair enough, but I posit X users started consuming this API when SOAP was prevalent and Y users started when ReST was prevalent and Y >> X. Furthermore, SOAP is hard to maintain these days because it's so ancient. i.e. the libraries are not new and/or actively maintained.
As such, I maintain SOAP should be gone for the good of the running system.
In Python you simply don't have good SOAP libraries. They were all started at the tail end of its popularity and then all died quiet deaths when attention shifted to ReST before they were actually production ready, and if you now want to talk to a SOAP service… well, better don't do it in Python. 2, that is. Forget about 3.
Nope. We needed one last September, zeep didn't yet exist back then.
And going by the bugtracker, it's running into quite a few problems with almost-but-not-quite compliant servers/WSDL files, which is a real issue when you're trying to interface ass-old legacy APIs (we're talking "not upgraded since 2006"-old) made by $BigEnterprise. Maybe this time the project won't die before they work out all the little kinks.
If that was ever true it certainly doesn't seem to be true now. All the tools support WSDL-first. All the tools are compatible with each other. Fill in the URL, let it autogenerate the interface, write your code and it all just works.
Because it was the latest trend 10+ years ago, and now people have made it just work because their applications are all built on it and people need actually good tools to use these architectures. It's always about tools, it's not like TCP is the best protocol or anything, it just has the best tooling, ditto for C, POSIX, etc. anything can be a good standard after 15+ years of work on it. Containers will be like that in a couple of years. It's all just cycles man.
