FIELD NOTE / 2026.09.212 MIN READ / 5 SOURCES

The Minds Behind JSON:API and Standardized Resource APIs – 7 People Redefining Software

Seven editors helped turn recurring JSON resource conventions into JSON:API, a standardized contract for resources, relationships, links, errors, inclusion, pagination, and extension.

TL;DR

Seven editors helped turn recurring JSON resource conventions into JSON:API, a standardized contract for resources, relationships, links, errors, inclusion, pagination, and extension. [1][2]

Why you should read it anyway

JSON made data exchange simple but left almost every higher-level convention unspecified. JSON:API addressed that gap by standardizing how resources, identifiers, relationships, links, included data, errors, and metadata are represented.

Imagine where JSON:API and Standardized Resource APIs would be without them

Without standardized resource formats such as JSON:API, client libraries and servers would continue inventing incompatible envelopes, relationship conventions, pagination formats, and error objects for otherwise similar HTTP APIs.

Time Estimate of how many years we would be hindered without them for human progress

Editorial counterfactual estimate: 2–5 years. This is not a measured historical fact. It is an editorial estimate of how much slower the field might have matured without this cluster of people, institutions, specifications, and tools.

The 7 people behind JSON:API and Standardized Resource APIs

1. Yehuda Katz

Why they matter: originally drafted JSON:API in 2013 from conventions developed around Ember Data, aiming to eliminate repeated ad hoc decisions in JSON resource APIs.[1]

2. Dan Gebhardt

Why they matter: became a core JSON:API editor and contributor, helping evolve the specification around resources, relationships, links, compound documents, and extension rules.[2]

3. Steve Klabnik

Why they matter: served as an early JSON:API editor and helped connect the specification with the broader Ruby, Web API, and developer-documentation communities.[3]

4. Tyler Kellen

Why they matter: served as an early JSON:API editor and contributor, helping stabilize specification language and community implementation practice.[4]

5. Ethan Resnick

Why they matter: served as an editor and made major contributions to the specification’s semantics, extensibility, profiles, and HTTP behavior.[5]

6. Gabe Sullice

Why they matter: became an active JSON:API editor and contributor, helping maintain and evolve the standard after its early adoption phase.[1]

7. Jeldrik Hanschke

Why they matter: became an active JSON:API editor, contributing to ongoing specification governance and maintenance.[2]

How they each differ from one another

Katz created the initial draft; Gebhardt, Klabnik, Kellen, and Resnick shaped the early specification; Sullice and Hanschke represent the continuing editor lineage that keeps the format governed and interoperable.

Final Take

JSON:API demonstrates that standardization can create leverage above the transport layer: when common representation decisions disappear, tooling and client code can become more reusable.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.

Submit a research lead

Please do not submit confidential material or claims you cannot support.