Hacker News new | past | comments | ask | show | jobs | submit login

There have been an explosion of API specification formats in the last few years. No clear winner has emerged.

JSON Schema and JSON Hyperschema are JSON-based formats for describing JSON and REST (hypermedia-driven) APIs. The formats make decent sense and can be used to generate docs, validators, client libraries, UIs, and more. http://json-schema.org/

API Blueprint is another emerging format for API description. It's written in Markdown, so it is very human-readable and -writable. It is not yet suitable for hypermedia APIs. Like JSON Schema, its tooling includes validators, client library generators, mock server generators, docs generators, etc. http://apiblueprint.org/

Swagger is a YAML-based format for specifying JSON APIs. It is meant to be created using the Swagger UI, rather than handwritten. It generates pretty docs, client software, etc. but is not suited to describing hypermedia APIs. http://swagger.io

Slate is an API documentation framework/template, designed to generate very handsome documentation pages. Its concern is more documentation than specification, and therefore doesn't concern itself with things like library or mock generation. https://github.com/tripit/slate

WADL is an API description language which describes API interactions in an XML format. It resembles WSDL. Not many people use it. http://en.wikipedia.org/wiki/Web_Application_Description_Lan...

Which of these is the best? Good question. I like JSON Hyperschema, but I am writing hypermedia APIs and the other formats here are lacking in their hypermedia support. API Blueprint is a nice format to write in a text editor and is easily read as-is or rendered from Markdown; no separate docs generator is necessary.




Yet another relatively new definition format: http://raml.org/


http://www.markus-lanthaler.com/hydra/

My recent choice, w3c track, sensible use case driven progression, growing adoption, flexible embedded or referenced meta-data as appropriate.

I've personally found great joy in being adaptive with the meta data in the responses, like presence of operations and accepted input on the operations depending upon data state and security context, something not really offered with json-schema.


I would also point out that API Blueprint allows you to describe your API responses with json schema. They sit at different levels - blueprint for specifying urls resources are accessed with, and json schema for validating the payload.


> Swagger ... is not suited to describing hypermedia APIs

Why is that? It wouldn't force/guide you to create a hypermedia APIs by default, but it could be used to document one couldn't it?


At least the last time I looked at Swagger, it was very much URL/endpoint-focused. Hyperlinks, while documentable, are not first-class citizens. In a real hypermedia-driven API, you want to document the links, not the URLs, as the API users will be using these named links, and not constructing URLs, to access functionality.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: