Live data from Hacker News

The Open API Initiative

openapis.org

21–23 of 23 posts

Re: The Open API Initiative

#21

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 resu…

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.

Re: The Open API Initiative

#22
post #19

Earlier quoted context omitted.

Yes, I mean documentation in general. It's fine to just show a long list of method signatures and class hierarchies, but a working code sample is the picture that's worth a thousand words.

You mean something like this: http://apidocjs.com/example/ generated from this https://github.com/apidoc/apidocjs.com/tree/gh-pages/source/...

Very nice! I particularly like the ability to compare two different versions visually.

Re: The Open API Initiative

#23
Too little, too late.

Thrift, gRPC, YaRPC, etc. are all RPC frameworks with strong typing and binary transports. They are still immature, but as such frameworks mature and support more languages, they will eat the lunch of any project trying to build on REST.

Post reply on HN