React, Flux, GraphQL, Hack, HHVM...? All of this and more!
With many tools failing to deliver on their promise of a universal and easy-to-use REST API, people continue to look for options. GraphQL is one of the strong options here, but it can become a bit heavy to implement for quick projects. The JSON API specification is an alternative.
Popular content management tools such as Drupal touted their RESTful APIs to bring headless capabilities to all. A year after the launch the project is still struggling to get momentum for their REST API. The reason is the complexity of their REST API. And Drupal is hardly alone with this trend as REST APIs leave the limelight, with other CMSes embracing GraphQL as they move to an API first approach.
Many tools have started adopting GraphQL as an alternative. GraphQL is definitely an improvement in usability terms over the plethora of atomic REST APIs, but it can be quite a bit of handful to create and consume. This is where JSON API steps in. Settling on a simplistic JSON structure, the tool offers CMS and application developers a no-frills way of defining APIs.
The introduction to JSON API from the project website tells it all, and many of us have been there:
If you’ve ever argued with your team about the way your JSON responses should be formatted, JSON API can be your anti-bikeshedding tool.
By following shared conventions, you can increase productivity, take advantage of generalized tooling, and focus on what matters: your application.
Clients built around JSON API are able to take advantage of its features around efficiently caching responses, sometimes eliminating network requests entirely.
Not only is the format drop-dead simple to generate for read situations, the specification supports writes and updates of resources as well. The specification has been stable since May of 2015, but continues to evolve in the form of experimental support for extensions to the protocol.