This is a hypermedia-optional, not-quite-RPC, not-quite-REST style spec that actually corresponds rather well with the kinds of JSON-on-the-wire, HTTP-as-a-prot

This is a hypermedia-optional, not-quite-RPC, not-quite-REST style spec that actually corresponds rather well with the kinds of JSON-on-the-wire, HTTP-as-a-protocol APIs that people in the 2010s tend to cook up. Their FAQ backs this up by saying: "(...) JSON API is an attempt to formalize similar ad hoc client-server interfaces that use JSON as an interchange format." Because this style of HTTP API is very common, this spec is more useful than it may seem. It's no secret that most "RESTful" APIs are not REST because hypermedia is an afterthought or missing completely. Specs like HAL and JSON-LD are intense in the sense that the problem domain requires careful ponderation, so most people don't go that route and never reach level 3 of the Richardson Model [1]. XML has fallen out of favor, JSON has schemas now (wow), RPC hasn't become fashionably mainstream again (although specs like gRPC, protobuf, Thrift have been trying). Code generators and WSDL-reimaginings like Swagger and RAML make it easy to spew JSON across the wire, so this spec forms a useful baseline, for sanity's sake. [1] http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm...