API Interface Standards: A formal history

The history of API standards has a consistent shape: a requirement appears, an implementation and its tooling win real adoption, and formal standardization follows.

Beneath that chronology, every API standard is an answer to the same small set of design decisions, and much of the history is the industry revising those answers as its constraints change. Four choices recur.

The first is the interaction model, whether the interface exposes remote procedures to be called, resources to be manipulated, a schema to be queried, or a stream of events to be consumed; this decision shapes everything a consumer must know to use the API.

The second is encoding and transport, the format on the wire (verbose but human-readable XML, compact JSON, or a dense binary layout) and the protocol beneath it (raw sockets, HTTP/1.1, HTTP/2, or a message broker), a trade of readability and debuggability against size and speed.

The third is the contract: whether the interface ships a machine-readable description that tooling can consume to generate clients, validate messages, and render documentation, or leaves the contract implicit and enforced only by convention.

The fourth is coupling: whether a client is bound to endpoints it must know in advance, or discovers the server’s capabilities at runtime. Cutting across all four are the perennial concerns of authorization, versioning, and error handling, and the governance question of who defines the standard and whether adoption precedes or follows ratification.

Read against these axes, each standard below is a particular judgment about where, for its moment and its constraints, the right trade-offs lay.

This is a chronological account of the standards that shaped application programming interfaces, the bodies that governed them, and the requirements that motivated each. It is organized by era. Within each era, the relevant standards are described in terms of their origin, governing organization, version history, and the technical or organizational need they addressed.

A note on dates: where a specification passed through a formal standards body, the date given is the ratification or publication date of the cited version. Version numbers and years should be checked against primary sources (W3C Recommendation records, IETF RFC publication dates, and each project’s release notes) before citation in formal work.

1. Remote procedure calls and distributed objects (1990s)

The first requirement was to invoke a procedure on a remote machine as though it were local. Sun’s ONC RPC (also called Sun RPC) established an early convention in the late 1980s, later documented in the IETF as RFC 1831 and successors. The Object Management Group (OMG) standardized CORBA, a language-neutral system of distributed objects with an Interface Definition Language (IDL) and the IIOP wire protocol, through the 1990s; it found its heaviest use in integration-dense domains such as telecommunications, banking, and defense, where the ability to bridge components written in different languages on different hardware justified the overhead. Microsoft pursued the same goal on its own platform with DCOM, which underpinned component communication in Windows enterprise software, and Sun provided Java RMI for Java-to-Java calls, the remote-invocation mechanism at the core of Java EE application servers.

These systems shared an ambition: a self-describing, language-neutral, object-oriented network fabric. They also shared a fate. CORBA in particular became a reference point for over-engineering, its complexity and vendor-specific incompatibilities limiting adoption outside large enterprises. The lesson carried forward: standards at the interface layer that demand heavyweight infrastructure and total buy-in tend to collapse under their own scope.

The transitional standard was XML-RPC, introduced in 1998 by Dave Winer of UserLand Software in collaboration with Microsoft. It encoded procedure calls and responses as XML sent over HTTP. It was deliberately minimal, and its constraints were the direct motivation for the larger specification that followed.

2. The XML web services era (1998–2007)

The requirement in this era was formal, tooling-driven, contract-first integration between enterprise systems, typically across organizational boundaries. The response was a stack of XML specifications governed primarily by the W3C and OASIS.

SOAP (originally Simple Object Access Protocol) grew out of XML-RPC. SOAP 1.1 was submitted to the W3C as a Note in 2000; SOAP 1.2 became a W3C Recommendation in 2003. SOAP defined an XML envelope for structured message exchange, independent of the underlying transport. Its formality suited high-stakes enterprise integration; payment networks, banking back-ends, healthcare and insurance systems, airline reservation and government services — and many such systems still expose SOAP endpoints today, long after the style fell out of fashion for new public APIs.

WSDL (Web Services Description Language) provided the machine-readable contract. WSDL 1.1 was published as a W3C Note in 2001 and saw the widest use; WSDL 2.0 became a W3C Recommendation in 2007. A WSDL document described a service’s operations, message types, and bindings in a form that tooling could consume to generate client and server stubs automatically. This is the significant point for the later history: the XML web-services era had a machine-readable interface contract from the outset.

UDDI (Universal Description, Discovery and Integration), standardized at OASIS, was intended as a registry for discovering services. It saw limited adoption and was largely abandoned.

The WS-* family extended the model with cross-cutting concerns: WS-Security (an OASIS standard in 2004) for message-level signing and encryption, WS-Addressing for transport-neutral routing, WS-Policy for declaring a service’s requirements, WS-ReliableMessaging for guaranteed delivery, and others. These addressed exactly the demands of regulated B2B exchange end-to-end security that survives intermediaries, auditable delivery guarantees, and machine-declared policy and remain in use where those demands persist. Collectively, though, they delivered rigor at the cost of substantial complexity and inconsistent interoperability between implementations. That cost became the motivation for the reaction that defined the next era.

3. REST and the web-native turn (2000–2008)

REST (Representational State Transfer) was defined by Roy Fielding in his 2000 doctoral dissertation. REST is not a specification or protocol; it is an architectural style expressed as a set of constraints on distributed systems, derived from the properties that made the web scalable. Its constraints include statelessness, a uniform interface, cacheability, and the hypermedia constraint (often abbreviated HATEOAS), under which a client is driven by hypermedia controls the server provides at runtime rather than by out-of-band knowledge.

In practice, the industry adopted REST’s lighter constraints (resource-oriented URLs, standard HTTP methods, standard status codes) and largely omitted the hypermedia constraint. What became known as “RESTful” APIs were predominantly HTTP-and-JSON interfaces with clients coded against known endpoints. This lighter form became the default for public developer platforms and mobile back-ends: it rode the existing web infrastructure, so ordinary HTTP caches, proxies, and load balancers worked without modification, browsers and command-line tools could exercise it directly, and its use of standard methods and status codes made it approachable without specialized tooling. Because REST carried no conformance test, interpretations varied widely, and the absence of a normative standard is a defining feature of the era rather than an oversight.

JSON (JavaScript Object Notation) supplied the dominant payload format. Specified by Douglas Crockford, it was published as IETF RFC 4627 in 2006, standardized as ECMA-404 in 2013, and issued as the interoperable standard RFC 8259 (and STD 90) in 2017. Its brevity relative to XML suited the emerging web and mobile clients.

Atom and the Atom Publishing Protocol represented a standards-track hypermedia approach in this period. The Atom Syndication Format was published as RFC 4287 in 2005, and AtomPub as RFC 5023 in 2007. AtomPub implemented REST’s hypermedia constraint more faithfully than most contemporaneous APIs, and influenced later thinking even as it saw limited direct adoption.

JSON-RPC, a lightweight remote-procedure-call convention over JSON, emerged around 2005, with the widely used 2.0 specification finalized in 2010. It remained relevant for cases where an RPC model suited the problem better than a resource model; it is also the message format later adopted by the Model Context Protocol.

4. Authorization and the API-as-product era (2006–2014)

Two requirements converged in this period: secure delegated access to APIs exposed to third parties, and consistent conventions for the JSON responses those APIs returned.

The organizational precedent predates the era. In 2002, an internal mandate at Amazon required all teams to expose functionality exclusively through service interfaces designed as if for external consumption. This decision, organizational rather than technical, established the pattern of the API as a durable, independently owned product with a versioned contract, and is frequently cited as a precursor to the platform strategy that produced Amazon Web Services.

OAuth addressed delegated authorization. OAuth 1.0 was published in 2007 and formalized as IETF RFC 5849 in 2010. OAuth 2.0, a substantially different framework, was published as RFC 6749 with the accompanying bearer-token specification RFC 6750 in 2012. OpenID Connect, an identity layer built on OAuth 2.0, was published by the OpenID Foundation in 2014. Together these became the default mechanisms for third-party API access and remain so, with later profiles (for example FAPI for financial-grade use) refining them for high-assurance contexts.

Several hypermedia response formats attempted to standardize self-description at the payload level, reviving REST’s under-adopted constraint. HAL (Hypertext Application Language) was proposed by Mike Kelly around 2011. JSON:API was drafted in 2013 by Yehuda Katz and Steve Klabnik and reached version 1.0 in 2015. Siren, Collection+JSON, and the JSON-LD family (JSON-LD reached W3C Recommendation status in 2014, with Hydra as an associated vocabulary) pursued related goals. Adoption was uneven. The recurring obstacle was that clients hardcoded against known endpoints derived little benefit from runtime hypermedia, so the formats saw use in specific ecosystems rather than becoming universal.

5. Description-language consolidation (2010–2017)

The requirement was a machine-readable contract for the HTTP-and-JSON APIs that REST-style development had produced without one, together with the tooling such a contract enables.

Swagger was the decisive entry. Development began in 2010 by Tony Tam at Wordnik, with the specification released publicly in 2011. Its adoption was driven substantially by Swagger UI, a tool that rendered a specification into interactive, browsable documentation. In March 2015, SmartBear Software acquired the Swagger specification. In November 2015, SmartBear donated it to a new body, the OpenAPI Initiative, established under the Linux Foundation, and the specification was renamed the OpenAPI Specification (OAS).

Two competing description languages had appeared in 2013: RAML, led by MuleSoft, and API Blueprint, from Apiary. Both offered arguably cleaner designs, but OpenAPI’s tooling ecosystem and neutral governance led the market to consolidate around it.

OpenAPI 3.0.0 was released in July 2017, adding reusable components, expanded security-scheme support, and improved extensibility over the 2.0 (Swagger) line. This established OpenAPI as the de facto standard interface definition language for REST APIs.

6. Typed and query paradigms (2007–2018)

Parallel to the description-language work, distinct interface paradigms emerged for problems that resource-oriented HTTP addressed poorly. Both major entries originated as internal systems at large technology companies and were subsequently open-sourced.

Thrift was developed at Facebook and released as open source in 2007, entering the Apache Software Foundation in 2008. It provided an interface definition language and cross-language serialization and RPC, aimed at efficient internal service communication.

Protocol Buffers, Google’s language-neutral serialization format, was open-sourced in 2008, with the proto3 revision following in 2016. It became the interface definition language for gRPC, a contract-first RPC framework Google announced in 2015, built on HTTP/2 and derived from its internal Stubby system. gRPC joined the Cloud Native Computing Foundation (CNCF), part of the Linux Foundation, in 2017. Its typing, binary encoding, and performance made it well suited to internal service-to-service communication, which became its dominant deployment context.

GraphQL was developed internally at Facebook beginning in 2012 to address over-fetching and under-fetching by mobile clients, and was open-sourced in 2015. It inverts control of the response shape: the client submits a query specifying the fields it requires, against a typed schema defined in the GraphQL Schema Definition Language. That inversion directly answered the mobile problem it was built for a single round trip returning exactly the data a screen needs, letting a bandwidth-constrained client avoid both the several requests and the discarded payload that fixed REST endpoints imposed. Stewardship passed to the GraphQL Foundation, under the Linux Foundation, in 2018–2019. In practice GraphQL was most widely adopted as an aggregation layer over existing services rather than as a wholesale replacement for REST, and its flexibility introduced operational concerns around query cost and caching that required additional governance.

OData (Open Data Protocol), developed by Microsoft from 2007 and standardized at OASIS as version 4.0 in 2014, defined conventions for queryable REST APIs, including a standard query syntax and metadata format that let a generic client filter, sort, page, and project over a data feed without any service-specific code. This made it a natural fit for exposing business data to analytics and reporting tools, and it retained a durable presence in enterprise and Microsoft-centric ecosystems, where products such as Dynamics, SharePoint, and Power BI speak it.

7. Event-driven and HTTP-layer standards (2015–2023)

As event-driven and streaming architectures became common, the requirement shifted to describing asynchronous interfaces, which the request-response model of OpenAPI did not cover, and to standardizing conventions that REST had left implementation-defined.

AsyncAPI was created by Fran Méndez in 2017 to describe message-driven and event-driven APIs, deliberately modeled on OpenAPI. It joined the Linux Foundation in 2021. Version 2.0 was released in 2020, version 3.0.0 in December 2023, and version 3.1.0 in early 2026. It is protocol-agnostic, supporting Kafka, MQTT, AMQP, WebSockets, and others through a bindings mechanism. In use, an AsyncAPI document plays the same role for an event-streaming platform that OpenAPI plays for a request-response API: it tells a producer what a channel’s messages must look like and a consumer what to expect, and it feeds the same class of tooling documentation, code generation, and validation for pipelines built on message brokers rather than HTTP calls.

CloudEvents, a CNCF specification that reached version 1.0 in 2019, standardized the metadata envelope for events so that event data could be recognized and routed consistently across systems and providers, independent of the messaging platform carrying it. Its practical value shows in serverless and multi-vendor architectures: because the envelope names an event’s type, source, and identifier in a fixed way, a function or router can dispatch on those fields whether the event arrived over Kafka, a cloud provider’s event bus, or plain HTTP, and events can cross provider boundaries without bespoke translation at each hop.

The HTTP standards themselves were revised in this period. HTTP/2 was published as RFC 7540 in 2015. In 2022 the core HTTP specifications were restructured into RFC 9110 (HTTP Semantics), RFC 9111 (Caching), and RFC 9112 (HTTP/1.1), with HTTP/2 re-specified as RFC 9113 and HTTP/3, running over QUIC, published as RFC 9114.

Problem Details for HTTP APIs standardized machine-readable error responses. RFC 7807 was published in 2016 and superseded by RFC 9457 in 2023, providing a common structure for reporting error conditions in HTTP APIs. It gave the error-handling axis a concrete default where REST had left one to every team’s invention: instead of each API returning an ad hoc error shape, a client can rely on a small set of standard members a machine-readable type, a human-readable title and detail, an HTTP status, and an instance identifying the specific occurrence, with room for extension members (such as a list of offending fields) and handle failures from unfamiliar services with the same code.

OpenAPI 3.1.0, released in February 2021, aligned OpenAPI’s schema model fully with JSON Schema and added top-level support for describing webhooks. Standardization of webhooks continued outside the specification as well, through community efforts to define consistent webhook payloads and verification.

8. Workflow and composition (2021–2025)

With single-operation description mature, the requirement advanced to describing how operations combine, and to adapting descriptions for different consumers. The OpenAPI Initiative addressed these by expanding from a single specification into a family of complementary specifications under one governance.

The Overlay Specification reached version 1.0.0 in 2024, defining a standard way to apply transformations to an OpenAPI description without modifying the source document, for example to localize or to tailor a description per audience.

The Arazzo Specification reached version 1.0.0 in 2024, with a 1.0.1 patch in January 2025 and a 1.1.0 revision adding support for AsyncAPI. Arazzo describes sequences of API calls as machine-readable workflows: the ordering of operations, the passing of outputs from one step into the inputs of the next, and success and failure criteria. Operations are referenced by their identifiers back into OpenAPI (and, as of 1.1.0, AsyncAPI) descriptions, allowing a single workflow to span synchronous and asynchronous calls.

OpenAPI 3.2.0 was released in September 2025, adding structured tags, first-class support for streaming media types, support for arbitrary HTTP methods, and OAuth 2.0 device-flow support, among other refinements.

OpenAPI 4.0, codenamed Moonwalk, is in early development. The Initiative has stated that it is prioritizing backward-compatible incremental releases in the 3.x line, with attention increasingly directed at making descriptions usable by AI systems.

9. Agent interoperability (2024–2026)

The most recent requirement is a standard interface between AI agents and the tools, data, and other agents they operate on. Several protocols emerged in close succession, and a notable feature of the period is their consolidation under neutral governance rather than fragmentation into proprietary systems.

The Model Context Protocol (MCP) was released by Anthropic in November 2024. It standardizes how an AI application connects to external tools and data sources: a server advertises its available tools, each with a natural-language description and an input schema, and a client discovers and invokes them at runtime. MCP uses JSON-RPC 2.0 as its message format. In practice it lets an assistant reach a codebase, a database, a file system, or a third-party service through one uniform interface, so the same client can drive any compliant server without integration code written per tool. It was adopted across the industry, including by organizations that compete with Anthropic, and in December 2025 was placed under the Agentic AI Foundation within the Linux Foundation. Its runtime-discovery model is a return to the self-describing-server principle that REST’s hypermedia constraint had described but that had lacked a client capable of consuming it.

The Agent2Agent (A2A) protocol was introduced by Google in April 2025 to standardize communication between independent agents. It uses HTTP and Server-Sent Events, and describes each agent through a capability document (an “Agent Card”) stating what the agent can do and how to reach it. A2A was donated to the Linux Foundation in June 2025.

The Agent Communication Protocol (ACP) originated with IBM and the AGNTCY collective (a group including Cisco, LangChain, and LlamaIndex), was announced in early 2025, and was contributed to the Linux Foundation in July 2025. Its design is deliberately REST-native and specified in OpenAPI, so that standard HTTP clients can interact with agents without protocol-specific tooling.

The Agent Network Protocol (ANP) is a community effort, initiated in 2024, oriented toward decentralized agent networks and identity.

The consolidation of these protocols under the Linux Foundation, and the tendency of the newest of them (A2A, ACP) to build on existing HTTP standards rather than replace them, characterize the state of the field as of mid-2026. Observed practice treats the protocols as addressing complementary layers rather than as direct substitutes, with multi-protocol coexistence expected in the manner of HTTP, WebSocket, and gRPC.

10. The locus of standardization

A structural observation spans the chronology. In the XML web-services era, standardization occurred within formal standards-development organizations: the W3C for SOAP and WSDL, OASIS for UDDI and the WS-* security stack. From the OpenAPI Initiative onward, the pattern shifted. Specifications increasingly originated as vendor or community open-source projects and were subsequently placed under a neutral host, predominantly the Linux Foundation and its sub-foundations (the OpenAPI Initiative, the CNCF, the GraphQL Foundation, and the Agentic AI Foundation). The IETF continued to govern the transport and cross-cutting layers (HTTP, JSON, OAuth, Problem Details).

The practical consequence is that modern interface standards tend to reach ratification after, not before, a working implementation and tooling ecosystem exists. Adoption has repeatedly preceded and driven standardization rather than following from it, and the availability of tooling has been a stronger determinant of which standard prevailed than the formal properties of the specification.

Bibliography and primary sources

Primary and authoritative sources are listed below, grouped to match the sections above. Standards bodies (IETF, W3C, OASIS, OMG) and the specifications’ official homes are cited in preference to secondary commentary. For living specifications, the links resolve to the latest version; use each site’s version index to reach a specific historical release. A few exact publication dates and deep links are best confirmed on the linked page.

1. Remote procedure calls and distributed objects

ONC RPC — IETF RFC 5531 (revising RFC 1831): https://www.rfc-editor.org/rfc/rfc5531
CORBA — Object Management Group: https://www.omg.org/spec/CORBA/
XML-RPC specification — UserLand: http://xmlrpc.com/spec.md

2. XML web services

SOAP 1.2 (W3C Recommendation) — W3C: https://www.w3.org/TR/soap12-part1/
SOAP 1.1 (W3C Note, 2000): https://www.w3.org/TR/2000/NOTE-SOAP-20000508/
WSDL 1.1 (W3C Note, 2001): https://www.w3.org/TR/2001/NOTE-wsdl-20010315
WSDL 2.0 (W3C Recommendation, 2007): https://www.w3.org/TR/wsdl20/
UDDI — OASIS: https://www.oasis-open.org/committees/uddi-spec/
WS-Security — OASIS Web Services Security TC: https://www.oasis-open.org/committees/wss/

3. REST and the web-native turn

Fielding, R. T., “Architectural Styles and the Design of Network-based Software Architectures” (2000 dissertation, Chapter 5 defines REST): https://ics.uci.edu/~fielding/pubs/dissertation/top.htm
JSON — IETF RFC 8259 (STD 90): https://www.rfc-editor.org/rfc/rfc8259
JSON — ECMA-404: https://ecma-international.org/publications-and-standards/standards/ecma-404/
Atom Syndication Format — IETF RFC 4287: https://www.rfc-editor.org/rfc/rfc4287
Atom Publishing Protocol — IETF RFC 5023: https://www.rfc-editor.org/rfc/rfc5023
JSON-RPC 2.0 specification: https://www.jsonrpc.org/specification

4. Authorization and the API-as-product era

Amazon service-interface mandate (2002) — Steve Yegge’s account, “Stevey’s Platform Rant” (archived): https://gist.github.com/chitchcock/1281611
OAuth 2.0 Authorization Framework — IETF RFC 6749: https://www.rfc-editor.org/rfc/rfc6749
OAuth 2.0 Bearer Token Usage — IETF RFC 6750: https://www.rfc-editor.org/rfc/rfc6750
OpenID Connect Core 1.0 — OpenID Foundation: https://openid.net/specs/openid-connect-core-1_0.html
HAL — IETF draft-kelly-json-hal: https://datatracker.ietf.org/doc/html/draft-kelly-json-hal
JSON:API: https://jsonapi.org/
Siren: https://github.com/kevinswiber/siren
JSON-LD 1.1 — W3C Recommendation: https://www.w3.org/TR/json-ld11/
Hydra — Hydra W3C Community Group: https://www.hydra-cg.com/spec/latest/core/

5. Description-language consolidation

OpenAPI Specification (latest) — OpenAPI Initiative: https://spec.openapis.org/oas/latest.html
OpenAPI Specification version index — OAI GitHub: https://github.com/OAI/OpenAPI-Specification/tree/main/versions
OpenAPI Initiative: https://www.openapis.org/
Swagger-to-OpenAPI history — Wikipedia (secondary, well-sourced): https://en.wikipedia.org/wiki/OpenAPI_Specification
RAML: https://raml.org/
API Blueprint: https://apiblueprint.org/

9. Agent interoperability

Model Context Protocol — official site and specification: https://modelcontextprotocol.io/
MCP introduction — Anthropic: https://www.anthropic.com/news/model-context-protocol
Agent2Agent (A2A) Protocol — official documentation: https://a2a-protocol.org/latest/
A2A specification repository — GitHub: https://github.com/a2aproject/A2A
Linux Foundation launch of the A2A project (June 23, 2025): https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
AGNTCY (Agent Connect Protocol / ACP; Cisco, LangChain, LlamaIndex): https://agntcy.org/
Survey of agent protocols (MCP, A2A, ACP, ANP) — arXiv 2505.02279: https://arxiv.org/abs/2505.02279

On sourcing

Where the account gives a version year (for example OpenAPI 3.0 in 2017, 3.1 in 2021, 3.2 in 2025; AsyncAPI 3.0 in 2023; MCP in 2024; A2A and ACP in 2025), the date is drawn from the linked specification’s release record or the governing body’s announcement. IETF RFC dates are the publication dates recorded at rfc-editor.org. Adoption figures and market-share claims are deliberately omitted from this account, as reliable primary measurement for them is scarce; where such figures are needed, they should be sourced separately and treated as directional. The characterizations of where each standard is used — the deployment domains, ecosystems, and named products cited to illustrate a standard’s purpose — are likewise illustrative rather than individually sourced, offered to convey typical usage rather than as exhaustive or measured claims.