I think it was the crappy auto-generated wrappers from back then that was the downfall. Both in c# and Java, there was too much magic, where they tried to hide too much and make it look like regular local function calls. People associated soap with the magic and when rest came along everyone jumped ship. But the problem was never with soap itself.
This swagger stuff is actually a step backwards, as rest was never meant to be used for api specifications anyway. Or at least the primary focus of it seemed to be hypermedia and evolutionary interfaces.
Neither swagger nor soap are really what I'd expect after 20 years of trying to come up with something though. Would have expected something far more powerful that has more of a functional style, allowing for various combinators and such to be generated.
> I think it was the crappy auto-generated wrappers from back then that was the downfall. Both in c# and Java, there was too much magic, where they tried to hide too much and make it look like regular local function calls.
I'd expand this a bit further too: they tried to make them look like regular function calls in an age where asynchronous/callback programming in general was a nightmare.
At least in C# today, a lot of the debug pain I recall helping other developers through with the old SOAP/WSDL WCF auto-gen code would be solved with async/await. Practically no one understood the Begin{FunctionName}Async/End{FunctionName}Async pattern that the best of those wrappers used at the time and so many developers settled for synchronous blocking and deadlocking anti-patterns instead.
Which again leads to the more general problem with such things that: when they worked right they were magic, and when they didn't work they were (practically) impossible to debug.
There is something to be said that, too, that no one wanted to write a WSDL definition file or a SOAP wrapper by hand, so you were always fighting your tooling to produce what you needed and had a hard time correcting it when it did something sub-optimal.
I don't think swagger is a terribly huge step backwards as in general what I've seen of swagger is lot more descriptive than prescriptive. I've seen some swagger-described APIs that are heavily hypermedia and take a strong REST approach, and I've seen some swagger-described APIs that might as well be SOAP for as much as they resemble "proper" REST and/or hypermedia. It certainly feels more pragmatic than SOAP/WSDL, in trying to describe a lot of the variety in how people build REST-ish APIs, and maybe in that way it's a step forwards from a once-sized-fits-all prescriptive approach. (In that way it too is a step backwards in that sometimes a good prescriptive approach might lead people more easily down a "happy path" of best practices, but that's always the hard balance: pragmatism versus theoretical purity. The pendulum swings.)
This. To expand on it a little more, if you ran into a poorly define wsdl, you'd get horrible looking objects back. Some even generate ambiguous "data" objects that essentially contain an xml string you'd have to parse yourself.
CORBA's IDL was great; we're using a home grown variant for C++/C#/Java/JS interop, and it's much, much better than SWIG.
Maybe the problem with a lot of RPC tools is that they conflate serialization format and remote call semantics (or "complect" these two factors, if I were inclined to mimic the pretentiousness of Rich Hickey).
I look at SOAP failures from a different perspective of ground truths rather than the ecosystem's potential.
In my experiences with SOAP and WSDLs, the code-generated java2wsdl and such wrappers were a way for many vendors to claim "we have an API to support your SOA!" when all they were doing was dynamically generating a WSDL file from a database schema (a lot of service desk and CMDB software like BMC Remedy and Atrium, HP Service Desk, etc. do this) and for a lot of enterprise applications that were basically made to sell a cash cow stack like an ITIL stack with CMDB. So your WSDLs constantly changed because every time someone changed a table's schema you'd need to generate and distribute the WSDL to everyone - this is a guaranteed workflow in an enterprise software situation with dozens of partners comparable to what happens when you get a call from your doctor that you have an STD. This pattern should also sound really familiar to the folks from the mid-90s - it's exactly the hell that began with CORBA objects and other systems that inevitably required everyone to recompile and redeploy their services whenever there was any schema change whatsoever, and unless you had a super-duper effective object AND service registry with accompanying object repositories all provided by some expensive vendor, your class definitions would routinely get desynced and you'd be forced to update your WARs and EARs if you didn't have more expensive hot-loading JVM plus correctly working lifecycle management that wouldn't leak memory (almost none did because of how difficult it was to write decent classloaders that would correctly use ephemeral and weak references for high-concurrency DBs). Thank goodness we had other options with message passing architectures in enterprise (Protocol Buffers, Thrift, etc. all got around the tyranny of class serialization that the distributed object enterprise architect Mafia wanted) but messaging has its own problems from a deployment perspective that made SOAP-based endpoints more attractive then.
This kind of centralized, byzantine, top-down design was the Holy Grail of enterprise application architecture that has ultimately failed in basically every single implementation I've seen or heard of except for the most trivial implementation cases or that required extremely authoritarian, didactic approaches resembling the Crusades or Gallic Wars rather than (now more common) collectivist collaboration toward software development. Either way, innovation slowed to a crawl as internal compliance and standardization become the only output of the software organization or nobody wanted to even try to evolve the system much over time. Open Source is not immune to this kind of bikeshedding culture.
The easier decoupling of services and ability for services to move at their own pace while freeing themselves from the data schema ERD-UML-death-squad-by-committee is what moving from the SOAP ecosystem bought us. The Enterprise Software Apocalypse's Four Horsemen surely included at least the names UDDI, ESB, and SOAP. While I sometimes miss a WSDL to make getting started with an API easier there is no way I miss the typical SOAP service that typically wrapped legacy command line applications older than myself and misrepresented them as something actually scalable or added 25 layers of class hierarchy to express a custom integer or string type for no apparent reason besides a Antediluvian form of input validation that combines the pedantry of Haskell typing with none of the power and elegance. These are not features that deliver business value to anyone besides enterprise software vendors and independent consultants seeking to overcomplicate every software system beyond the comprehension of its own engineers.
TL;DR - I'm afraid that we're starting to regress back to what the J2EE ecosystem tried and failed to do even within monolithic companies because many people never had to design and (more importantly) operate and maintain these centralized, specification-first APIs that have historically hurt innovation and collaboration, not helped.
I remember playing with the SOAP API of gforge advanced (PHP), and it was not a pleasant experience.
What specially bothered me was how this API tended to return internal IDs instead of resolving them server side and directly give high level and useful information. And there was other issues like returning html escaped text instead of the raw text directly.
It really gave me the impression of an API exposing the raw sql tables.
In the end, I managed to do what I wanted (export the tickets to automatically generate a changelog), but it took me quite a lot of time and a disproportionate amount of code (vs an API like the github one).
This swagger stuff is actually a step backwards, as rest was never meant to be used for api specifications anyway. Or at least the primary focus of it seemed to be hypermedia and evolutionary interfaces.
Neither swagger nor soap are really what I'd expect after 20 years of trying to come up with something though. Would have expected something far more powerful that has more of a functional style, allowing for various combinators and such to be generated.