News for hackers. Stuff that matters.
Re:The Open API Initiative by palakchokshi on Friday March 11, 2016 @03:37PM (#11269306)
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.

Re:The Open API Initiative by doublerebel on Friday March 11, 2016 @04:45PM (#11269779)
Auto-generated client side consumers for APIs already exist, and are quite useful: 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.

Re:The Open API Initiative by sinzone on Friday March 11, 2016 @11:17PM (#11271376)
Already happening. Tools (like 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.
Re:The Open API Initiative by Mikhail_Edoshin on Saturday March 12, 2016 @11:11AM (#11273327)
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.