Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

I used a service once, just recently, whose API was SOAP (I think it was the one for VoIP.ms?)

Instead of documenting their API, they gave me a WSDL file to download and told me to plug it into any WSDL-supporting SOAP client.

So I threw it into http://fagiani.github.io/savon/ in a Pry session, got back an object representing the API gateway, and then just... started exploring the API using it and Pry, treating the objects and their properties the way I would those of a regular Ruby library.

It was honestly a nice experience, and it would have been even nicer if I had to deal with more than one API, because I could have just kept dealing with Savon rather than finding a new (maybe not-very-well-written) client library for each new service.

So, I don't get the hate for SOAP/WSDL. Is it the process of building the SOAP service that's frustrating? The process of creating the WSDL document? I didn't have to deal with either of these, so maybe that's where the hatred boils up from.

Was it integrating code-generation into the build process? Again, since I was using a dynamic language (Ruby) whose SOAP library (Savon) parsed WSDL and built up its client-proxies in memory at runtime, I didn't have to deal with this.

Or was it dealing with brittleness and edge-cases and a lack of fidelity in the types you could pass through such APIs? I didn't have a problem with this personally, but I might have just been dealing with a uniquely-well-architected backend service.

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.

Maybe GraphQL is that more powerful future you imagine.

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.

Very nice description, your only mistake was writing in the past tense.

The enterprise architect mafia just got new toys. :)

Even outside J2EE, SOAP can be quite horrible.

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).

I still have the code, but I'm far from proud of how it turned out: https://github.com/kakwa/gforge-soap-client/blob/master/gfor...

Those crappy generated wrappers existed before, as Sun RPC, CORBA, DCOM, Taligent, Talos, and many others whose name I've forgotten.

And will keep on coming back even after REST gets replaced something else.

Most want a simple network programming model that looks like regular code, even though distributed systems are anything but simple.

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).

>So, I don't get the hate for SOAP/WSDL.

AFAIK one of the sources of hatred for SOAP is people building the message bodies by hand using browser JS instead of using a code generator (one might not have existed for browser JS at that time). Not only was it complicated by being XML, but SOAP bodies are especially verbose XML.

lack of cacheability is the main issue I've heard

It's usually extra hostile for things like caching. I've (on multiple occasions) seen one URI endpoint, http posts and method as a separate header. Pretty much as far away from a sane caching best practice as you can go. Also; a lot of these older web services doesn't support deflate, gzip (accept-encoding, vary, ..) so your average responses are 500kb and up. :'(

In a recent project, a client saturated their wire as a result of just this.

My main frustration with soap services is that when it works it's great, but when something is wrong and you don't control the server side it's really frustrating to figure out what's wrong. Too often wsdl descriptions for 3rd party apis are desperately out of date, and debugging api call by looking at xml with auto-generated type definitions is hell. SOAP is just not human-friendly enough, it's too complex. In the end the most popular formats always end up being the ones that are easiest for humans to process & debug: plain text commands in telnet/pop3/smpt, html, json, restful calls, etc.

I think it's quite "fun" to keep track of different versions in SOAP, though there's probably a WS-VERSIONING spec plugin that describes a way to do it. That was certainly the source of cursing that I picked up from sitting adjacent to colleagues who maintained a SOAP API.

Also having integrated against a couple SOAP APIs, it's a bit annoying to write API client tests using recording / mocking of HTTP requests -- since the first thing your client has to do is actually grab the WSDL, your recordings are bloated. (I use VCRpy a lot for this use-case, and it's very convenient for REST APIs.)

Not sure where the best practices are on bundling a copy of the WSDL with your binary; not sure if your app can survive the WSDL spec changing under your feet, but at the same time, if the API changes its spec using a cached version of the WSDL won't work either.

Reply on news.ycombinator.com