Even though SOAP itself was oftentimes unwieldy to work with, i've always found the fact that every API has a clear definition that can be fed into a tool of some sort to either generate client code in my language of choice, or to allow programmatically testing it to be a wonderful time saver. For example, tools like SoapUI can import WSDL and allow you to be up and running with an external service in a matter of minutes, making testing and discovering such services really easy: https://www.soapui.org/docs/soap-and-wsdl/

Now, when it comes to REST, it feels like for a while there was nothing like that, at least before Swagger became popular. In my eyes, it essentially attempted to do the same, but with JSON/YAML definitions. Eventually we ended up with OpenAPI: https://spec.openapis.org/oas/latest.html

However, at the same time, it feels like the people behind Swagger and OpenAPI tried reinventing the wheel, since WADL already existed (published in 2009 vs Swagger 1.0 in 2011) and seemed to be the equivalent to WSDL: https://www.w3.org/Submission/wadl/

So here's my question: why didn't WADL become popular and why is OpenAPI more popular instead?

To gauge OpenAPIs popularity, just look at: https://openapi.tools/

WADL has nothing of the sort. Why?

As a counterpoint, some people might claim that REST in of itself is enough and that neither WADL, nor OpenAPI are strictly necessary: https://stackoverflow.com/questions/1312087/what-is-the-reason-for-using-wadl

With that, however, i disagree. When i develop a web API or integrate with an existing one, i want the tooling to do a lot of the work for me - to pull the service definitions from the source, generate all of the code that i need to interface with it and also alert me of any breaking changes, should these auto generated pieces of code no longer fit with the rest of my solution after an update (say, a method has been removed/deprecated). Feel free to share your views on this as well!