I was told I should be using swagger, and upon learning more about I started asking why they didn't just build tooling around WSDL. I couldn't see anything enabled by Swagger that isn't enabled by WSDL.
About the only thing I could think of was simplicity due to it being more specialized than WSDL.
I was told javascript can consume swagger easier, which may be true, but I don't know why that's a significant problem with WSDL seeing as how you could autogenerate the javascript interfaces anyway.
I still can't really wrap my head around what problem Swagger is solving that wasn't already solved by WSDL.
The problem with WSDL, at least at its inception, was that it tied in with the whole WS-* extravaganza, a set of standards that are built on top of each other and heavily based on XML. While WSDL has evolved to support RESTful services, early WSDL was closely tied to SOAP.
The XML thing is slippery slope. Suddenly your toolchain has to be aware of namespaces, XSD schemas, and so on. It's a largeish universe of a standards that sound good on paper but don't contribute meaningfully to anyone's productivity. And XML has historically been (and still is) popular with the enterprise Java crowd — J2EE, Spring and so on — there's a pretty steep divide between that and the more agile world of web devs and startups. If you're buying into the XML stack, WSDL will seem like a nuisance more than a productivity multiplier.
That said, I don't think Swagger/OpenAPI is very good, either. It's replacing XML with YAML, and introducing its own set of issues. And the community and tooling ecosystem aren't quite there.
The question I posed in the discussion is why they didn't extend WSDL instead of trying to rebuild the entire ecosystem by creating Swagger.
To me the XML/JSON thing is a non-issue. I've never really gotten the unreadability of XML argument given a decent prettifier (which also applies to JSON), especially for something like a web service description.
I guess my thing is, we already have a web service description language, it's called WSDL, and it's already been extended to support REST, why not extend it to support whatever use case you have, or build the tooling around it to support said use case?
You could have easily built the Swagger Spec to spit out WSDL instead of JSON. It means you would have been able to lean on the existing tools that can swallow a WSDL file instead of having to recreate the entire ecosystem yourself.
What I kept getting back was "JSON > XML" and to me that's just a non-issue. It's so far down the list of what's important that I can't imagine making the decision to try and recreate all the tooling around WSDL for it.
And I guess I've never really had your experience with WSDL because I've never been forced to be aware of namespacing issues any further into my system than the edges. Perhaps I've been lucky, but I've been using WSDL for years to ease integrating into web services and I've never stopped and thought to myself that it would be better in JSON with a YAML spec. And I rarely deal with SOAP nowadays, and when I do, I just use a library to swallow the WSDL and do the right thing.
I guess that's really where I'm coming from. It smacks of religion to me.
I was told I should be using swagger, and upon learning more about I started asking why they didn't just build tooling around WSDL. I couldn't see anything enabled by Swagger that isn't enabled by WSDL.
About the only thing I could think of was simplicity due to it being more specialized than WSDL.
I was told javascript can consume swagger easier, which may be true, but I don't know why that's a significant problem with WSDL seeing as how you could autogenerate the javascript interfaces anyway.
I still can't really wrap my head around what problem Swagger is solving that wasn't already solved by WSDL.