I know that some people suggest that perhaps RESTful APIs (or even some other types of APIs) shouldn't try for formal specifications, but personally I find OpenAPI to be great, especially when combined with a bit of codegen and automation, like in the article!
Somehow I think that the workflow of SOAP + SoapUI was superior to much of the ad-hoc messing about that came afterwards in the earlier days of large scale REST adoption (before Swagger was quite a thing), despite SOAP itself not being all that great. Regardless, you could get the service spec as a WSDL file and feed it into either SoapUI to get a full API client for testing, or maybe throw it at some codegen to get client stubs in Java or whatever language you were using.
It's nice to see that we're getting close to that automation and codegen again, given that REST is easier to work with than SOAP in most cases. I just wish that more projects out there truly embraced OpenAPI as well, which in my experience hasn't been the case (honestly, tooling should automatically generate basic OpenAPI specs from the routes that your app exposes).
JetBrains tooling is pretty good, as always, though.
Somehow I think that the workflow of SOAP + SoapUI was superior to much of the ad-hoc messing about that came afterwards in the earlier days of large scale REST adoption (before Swagger was quite a thing), despite SOAP itself not being all that great. Regardless, you could get the service spec as a WSDL file and feed it into either SoapUI to get a full API client for testing, or maybe throw it at some codegen to get client stubs in Java or whatever language you were using.
It's nice to see that we're getting close to that automation and codegen again, given that REST is easier to work with than SOAP in most cases. I just wish that more projects out there truly embraced OpenAPI as well, which in my experience hasn't been the case (honestly, tooling should automatically generate basic OpenAPI specs from the routes that your app exposes).
JetBrains tooling is pretty good, as always, though.