[wycats]

Ultimately, the value prop of a tool like Graphiti or GraphQL is independent of the exact details of the wire format.

Graphiti uses JSON:API[1] under the hood as its protocol, which is a language-independent protocol with a wide variety of clients[2], and is now built-in to Drupal[3].

I designed JSON:API in ~ 2013 with a narrow purpose: to describe a protocol for incrementally communicating with server-side graphs over HTTP.

By incremental, I mean the possibility of fetching exactly the data you need at first, but then slowly filling in more data over time as a user interacts with an application.

URLs are a great "internet pointer", so when I was looking for a way to link fetched data with other not-yet-fetched data, URLs were the natural answer. On the other hand, a lot of REST APIs at the time didn't have a good way to eagerly send a whole bunch of graphy data down at once.

JSON:API's concept of linkage supports both models: a type/id pair for data the client already knows about and a URL for data it doesn't. You can even combine the two, to enable incremental refreshing of a piece of data that you fetched as part of the first request (simply by hitting the URL).

JSON:API was designed to work well with many kinds of client-side approaches, including ORMs. This meant using a composite key of type/id to identify records and not just a single ID. Over time, this has become a best practice for other tools in the space[4][5]

OData exists in a similar space as JSON:API, but JSON:API is much more tightly focused on the problem of incrementally fetching a graph of data from the server into the client. Focus is good :)

[1]: https://jsonapi.org/ [2]: https://jsonapi.org/implementations/ [3]: https://www.drupal.org/project/jsonapi [4]: https://graphql.org/learn/queries/ [5]: https://levelup.gitconnected.com/basics-of-caching-data-in-g...