5 ms·

Next will come the API spec parsers to automate client code generation. Those will break on the first vendor specific extension. Vendors will put in extensions

Next will come the API spec parsers to automate client code generation. Those will break on the first vendor specific extension. Vendors will put in extensions for security, pre and post request action guidance, etc. This will cause vendor specific client code generators to be created. The specification will take a long time to get updated as each vendor will want their extensions in the core specification. As a result even more extensions will be created. We have seen this cycle before with WSDL and XML Schema, etc. I hope we have learned from our mistakes and don't go down the same path to have history repeat itself. Personally I like the idea of an API Specification but the practical use has been a let down so far.

doublerebel 11y ago
Auto-generated client side consumers for APIs already exist, and are quite useful: https://apimatic.io https://apimatic.io . If we can get producers to standardize all or part of their API, then we gain the ability to switch easily between providers and force them to compete on service instead of proprietary lock-in. Ideally.
sinzone 11y ago
Already happening. Tools (like https://gelato.io https://gelato.io) provide auto-generated docs, live test-console, code snippets and SDKs from your Swagger file. It comes with a free plan for OSS projects.
Mikhail_Edoshin 11y ago
I'm not sure about WSDL, the only thing I understand about it is that it was originally viewed as a simplified version of CORBA for Web :) But did XML Schema actually had that cycle of incompatible extensions you describe? I agree it's a bit heavyweight, but otherwise its concept is pretty clear and solid. To me HTML and CSS look more like vendor extension soup you describe. That said, there certainly will be extensions, because REST as it is is not sufficient for many scenarios. Take WebDAV, for instance: it has locks, batch updates, queries, standard support for sync, etc. REST has nothing of this sort. Have you ever tried to sync a large dataset against a typical REST API? It's very painful. While REST is simple, this simplicity mostly comes from being very basic. And WSDL and XML Schema are complex not because their authors are stupid (addition: or because there was some political wars), but because the subject itself is complex.

doublerebel 11y ago

Auto-generated client side consumers for APIs already exist, and are quite useful: https://apimatic.io https://apimatic.io . If we can get producers to standardize all or part of their API, then we gain the ability to switch easily between providers and force them to compete on service instead of proprietary lock-in. Ideally.

sinzone 11y ago

Already happening. Tools (like https://gelato.io https://gelato.io) provide auto-generated docs, live test-console, code snippets and SDKs from your Swagger file. It comes with a free plan for OSS projects.

Mikhail_Edoshin 11y ago

I'm not sure about WSDL, the only thing I understand about it is that it was originally viewed as a simplified version of CORBA for Web :) But did XML Schema actually had that cycle of incompatible extensions you describe? I agree it's a bit heavyweight, but otherwise its concept is pretty clear and solid. To me HTML and CSS look more like vendor extension soup you describe. That said, there certainly will be extensions, because REST as it is is not sufficient for many scenarios. Take WebDAV, for instance: it has locks, batch updates, queries, standard support for sync, etc. REST has nothing of this sort. Have you ever tried to sync a large dataset against a typical REST API? It's very painful. While REST is simple, this simplicity mostly comes from being very basic. And WSDL and XML Schema are complex not because their authors are stupid (addition: or because there was some political wars), but because the subject itself is complex.