hidekazu-konishi.com

API Design Paradigms History and Timeline - XML-RPC, SOAP, REST, gRPC, GraphQL, and OpenAPI

First Published: 2026-09-12
Last Updated: 2026-09-12

The system in front of you is built using SOAP. New components are being developed using REST. Voices inside the company now want to add GraphQL and gRPC. In this situation, the question that often arises first is which one is the newest. However, this question isn't helpful in making a decision.

This article presents a timeline of the lineage of API design paradigms - the arrangements that govern how applications call each other's functions. It's not a comparison of features. Instead, it focuses on which generation discarded what from the previous generation, and what aspects were carried forward. It also highlights instances where features that were once abandoned have reappeared, indicating the publication dates of the relevant specifications.

This timeline differs from other technology histories in one key aspect: none of these generations has ended. SOAP 1.2 remains a W3C Recommendation. So does WSDL 2.0. While HTTP/1.1's RFC has been superseded, REST isn't documented by any standardization body, so there isn't a document that needs to be formally retracted. The publication of a new specification doesn't necessarily mean that the previous one has been deprecated. This article demonstrates this distinction by referencing the primary sources from each organization.

This article does not evaluate the merits of any particular specification. It doesn't address which one to choose or which one to migrate to. It also avoids discussing adoption rates or market share. It doesn't make judgments about the merits of license terms. Instead, it simply records which documents were published on which dates and what their current status is. It also refrains from speculating about the reasons behind any decisions, especially when the official documentation doesn't provide an explanation.

All information presented in this article was verified as of September 11, 2026.

Related articles on hidekazu-konishi.com:

• Tool Use and Agent Protocol History and Timeline - Function Calling, MCP, and A2A
• Model Context Protocol Specification Version Timeline - Version-by-Version Changes and Adoption Milestones
• Real-Time and GraphQL API Architecture with AWS AppSync - Resolvers, Subscriptions, Authorization, and Conflict Resolution
• Amazon API Gateway Decision Guide - REST, HTTP, and WebSocket APIs and Integration Patterns
• AWS History and Timeline regarding Amazon API Gateway - Overview, Functions, Features, Summary of Updates, and Introduction
• Observability and OpenTelemetry History and Timeline - Competing Specifications, a Foundation Merger, and the Path to a Single Standard

Background and Method of Creating the API Design Paradigm Timeline

What Counts as a Turning Point Here

This timeline is not exhaustive. This field has numerous specification versions, and listing them all would not fully reveal the evolution of these technologies. Only the following five types of row were selected:

1. Rows marking the public announcement of a fundamental design paradigm — The rows on which a document defining a new way of calling was first published.
2. Rows reflecting changes in the standardization status of a document — Changes from a Note to a Recommendation, or changes in the status of an RFC.
3. Rows indicating changes in ownership or management of a specification — Donations, license modifications, the establishment of a foundation, or acceptance by an organization.
4. Rows establishing a foundational format — Formats like XML, JSON, and HTTP, which serve as the basis for other specifications.
5. Rows related to the evolution of machine-readable interface descriptions — This is the primary focus of this article.

⛔ Rows for implementation releases or library releases were not included. The number of client implementations in each language is too large, and they evolve at a pace separate from the evolution of the specifications. The exception is when an implementation was publicly released instead of a specification document. For example, gRPC did not follow the pattern of releasing a specification document first, so the date the implementation was released is what is recorded.

The Primary Sources This Article Used

Each row includes the URL for the corresponding primary source. The following categories of sources were utilized:

• W3C TR pages — SOAP, WSDL, XML, and XML Schema. The exact wording of the status section at the top of each page was read as written.
• W3C Process Documents and the page defining the types of published documents — Procedures for retiring Recommendations and the definition of the resulting status. This article can state that none of the specifications have been withdrawn because the W3C itself defines what constitutes a withdrawal.
• IETF datatracker — HTTP and JSON RFCs. In addition to the number and publication date, the current status and relationships to superseded versions (Obsoletes) were reviewed.
• The original distributors of the specifications — Version lists from spec.graphql.org, version lists and Revision History from spec.openapis.org, jsonrpc.org, and xmlrpc.com.
• Foundation records — Press releases from linuxfoundation.org, project pages from cncf.io, and announcements from openapis.org.
• Official announcements from the developers — Google's open source blog and Cloud Blog, Meta's engineering blog, and Anthropic's news.
• An academic document published by its own author — Roy Fielding's dissertation.

⛔ Secondary media and summary articles were not treated as primary sources. This topic has a large number of secondary articles, and some of them round off dates and scope. Areas prone to rounding off will be explicitly mentioned in the text.

⚠ This article does not use AWS documentation. Determining when AWS implemented each specification is a separate historical record in itself. Relevant rows have been delegated to existing publications.

The Type Column

Each row in the timeline includes a designation indicating the type of date. This is to avoid using the same terminology to describe both the publication of a document and the completion of standardization. The values used are as follows:

• W3C Note — Rows for documents W3C published as a Note. A Note does not carry an endorsement from W3C.
• W3C Recommendation — Rows for documents W3C published as a Recommendation.
• RFC — Rows for documents the IETF issued as an RFC. The body of each row gives the status and the Obsoletes relationship.
• Spec release — Rows indicating the release of a specification version.
• Dissertation — Rows representing documents published as academic dissertations.
• Open sourced — Rows indicating that an implementation was released as open source.
• Donated — Rows representing specifications that were donated to an organization.
• Relicensed — Rows indicating a change in the specification's license.
• Foundation — Rows representing the establishment of a foundation, or the announcement of intentions to establish one.
• CNCF — Rows representing the acceptance of a project by CNCF, or a change in its maturity level.
• WG closed — Rows representing the closure of a standardization working group.
• Announcement — Rows representing the announcement of the formation of an organization or the commencement of a new initiative.

Why the Date Precision Differs from Row to Row

This article's timeline does not provide daily precision for every row. The reason for this lies in the nature of the primary sources.

• W3C documents have dates directly associated with the page itself, allowing for daily precision.
• RFCs only specify the month and year of publication. This article writes RFC rows by month and year, without adding daily precision.
• Dissertations, such as Fielding's dissertation, only indicate the year. The row for Fielding's dissertation lists only the year, without specifying the month.
• Announcements from companies and foundations have publication dates listed on the announcement itself, allowing for daily precision.
• Versions of specifications are associated with version lists from the distributing organization, which include dates, allowing for daily precision.

⚠ This article does not invent a date in order to make the precision uniform. While some secondary articles may include publication dates for RFCs, the primary source at the IETF only provides month and year.

Why Two Different W3C URLs Appear for the Same Specification

⛔ There are two types of URL used for W3C documents. Citing them without observing this difference throws off either the date or the status, every time.

• URLs with dates (e.g., /TR/2003/REC-soap12-part1-20030624/) refer to a specific version of the document as it was published on that date. The content of these URLs is fixed and does not change.
• URLs without dates (e.g., /TR/soap12-part1/) refer to the latest version of the specification. If a new version is released, the content at the same URL will be updated.

⇒ This article uses these two types of URLs strategically. When referring to a specific state of the specification as it existed on a particular date, it uses URLs with dates. When describing the state as of the verification date, it uses URLs without dates.

⚠ Therefore, the only specifications whose current status this article verified are the ones cited through a URL without a date. The rows referring to XML 1.0 and XML Schema 1.0 point to versions from 1998 and 2001, respectively, and this article does not cover any subsequent versions.

What This Timeline Does Not Include

What was not included, and why, is stated up front.

• CORBA and DCOM. Object-oriented RPC technologies like these predate XML-RPC, representing a prior stage in the lineage. However, this article focuses on design paradigms that operate over HTTP. These two technologies have fundamentally different underlying assumptions, so they are not included. ⛔ This article will not discuss what XML-RPC simplified compared to these two. No primary document stating the design intent of the time could be verified.
• OData, JSON:API, AsyncAPI, and tRPC. While all of these are real specifications, they do not fit the thread this article follows, in which something discarded returns later. They are stated as excluded so that the timeline does not present a false sense of completeness.
• The 1998 side of XML-RPC. The fact that this protocol was operational in 1998 is evident from the specification itself. However, no primary document published in 1998 could be verified for this article. The relevant row carries the details.
• Every version of each specification. GraphQL has seven versions, and OpenAPI has more than ten. This article only focuses on the versions that marked a significant shift in the lineage, and the most recent versions as of the verification date.

What This Article Leaves to Other Articles

This article covers only the lineage of the specifications. Existing publications cover the implementation details and the design processes.

• The lineage of the Model Context Protocol and Agent2Agent is the subject of the existing publication Tool Use and Agent Protocol History and Timeline. This article simply notes the current state of this lineage with a single row.
• Changes to each version of the Model Context Protocol are documented in the existing publication Model Context Protocol Specification Version Timeline. This article does not specify version numbers.
• The design process for GraphQL and how to write schemas are covered in the existing publication Real-Time and GraphQL API Architecture with AWS AppSync.
• Whether to choose REST API or HTTP API is discussed in the existing publication Amazon API Gateway Decision Guide. This article does not outline selection criteria.
• Information on when AWS implemented specific specifications can be found in the existing publication AWS History and Timeline regarding Amazon API Gateway.
• The process by which specifications evolve and consolidate into a single standard is addressed on a different subject by the existing publication Observability and OpenTelemetry History and Timeline.
• The authentication and authorization mechanisms that sit on top of these calls are part of a separate lineage related to SAML, OAuth 2.0, and OpenID Connect. This article does not address this topic.
• The other two articles published alongside this one address the same principle – that a new layer does not erase the previous layer – but cover different topics. Details on directories and IDs are in Microsoft Identity History and Timeline, while routing is covered in AWS History and Timeline regarding AWS Transit Gateway. This article focuses on calling conventions.

API Design Paradigm Historical Timeline (Updates from February 10, 1998)

The following is a timeline of API design paradigms. Rows are ordered chronologically, and each row includes a link to its primary source.

Use the following index to navigate by year:

• 1998 - The foundational structure solidifies, and the initial design paradigm and initial description format emerge.
• 2003 - Recommendations are finalized, and the working group that created them is dissolved.
• 2010 - The foundation shifts from XML to JSON, and machine-readable interface descriptions reappear under a different name.
• 2015 - Three design paradigms emerge over a three-year period.
• 2018 - Specification management is transferred to the foundation, and HTTP finally becomes an Internet Standard.
• 2024 - Machine-readable interface descriptions once again become a requirement.

1998-2001 - The Envelope Arrives, and So Does the Description

During this period, the fundamental elements of the topic discussed in this article were almost entirely in place. ⚠ It's important to note that both SOAP and REST emerged in the same year. Looking back, REST can read as a reaction against SOAP, but the dates in the primary sources do not line up that way.

Date	Family	Type	Summary
1998-02-10	XML	W3C Recommendation	XML 1.0 became a W3C Recommendation. The document status is listed as W3C Recommendation 10-February-1998. ⇒ From this date, it became possible to write data in a format that both humans and machines could read, regardless of its structure. The design paradigms that would emerge over the next five years were all built upon this format. This article focuses on XML as a foundational technology, not as a design paradigm itself. Rather, it serves as the underlying basis that subsequent specifications rely upon. References: Extensible Markup Language (XML) 1.0
1999-06	HTTP	RFC	HTTP/1.1 was released as RFC 2616. The status was a Draft Standard. ⚠ This document was later superseded. It was replaced by six documents from RFC 7230 to 7235 in 2014, and then replaced again with a different set in 2022. ⇒ For the purpose of this article, what is important is that the IETF has a mechanism for explicitly recording these replacements. This point is contrasted with the W3C in a later section. References: RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
1999-06-15	XML-RPC	Spec release	The specification for XML-RPC was published. The document's signature line reads Tue, Jun 15, 1999; by Dave Winer. ⚠ It can be read from the specification itself that this protocol was operating since 1998. The copyright notice states 1998-2003, and the HTTP response examples in the specification include a date of Date: Fri, 17 Jul 1998 19:55:08 GMT and a Server: UserLand Frontier/5.1.2-WinNT identifier. ⛔ However, this article has not been able to verify the primary document published in 1998. The article dated July 14, 1998, which the specification references as non-technical commentary, could not be reached at the host as of the verification date. ⇒ Therefore, this article does not create a row for 1998, and makes a row only of the date the document was signed. References: XML-RPC Specification
2000	REST	Dissertation	Roy Fielding's dissertation gave REST its name. The dissertation is titled Architectural Styles and the Design of Network-based Software Architectures, was submitted to the University of California, Irvine, and the year listed on the title page is 2000. Chapter 5 is titled Representational State Transfer (REST). ⚠ The date listed here is only the year. This is because the document itself only provides the year, and this article does not attempt to fill in the month and day. ⛔ At this point, REST is not a protocol. The dissertation defines an architectural style, not a format for data or a set of transfer procedures. ⇒ This distinction would later contribute to the perception that REST lacks a formal specification. References: Architectural Styles and the Design of Network-based Software Architectures
2000-05-08	SOAP	W3C Note	SOAP 1.1 was published as a W3C Note. The title is Simple Object Access Protocol (SOAP) 1.1. ⛔ A Note is not a Recommendation. The document explicitly states that the W3C does not recommend it. ⇒ Therefore, from the outset, SOAP 1.1 was not a W3C standard. The common summary that SOAP became a W3C standard before fading away contradicts the primary sources. It was three years later that SOAP 1.2 became a standard. The verbatim wording is placed in a section after the timeline. ⚠ The same year saw the publication of Fielding's dissertation on REST. These two technologies emerged around the same time, but in separate contexts. References: Simple Object Access Protocol (SOAP) 1.1
2001-03-15	WSDL	W3C Note	WSDL 1.1 was published as a W3C Note. This is the first form of machine-readable interface description that this article tracks. The document's abstract begins: WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. ⇒ For the first time, it became possible to describe, in a format readable by machines, not just for humans, what operations were available, what types of arguments they took, and what types they returned. The description is divided into two layers: abstract and concrete, connecting abstract operations to specific protocols and message formats to define endpoints. ⛔ WSDL 1.1 is also a Note. It carries exactly the same non-endorsement wording as SOAP 1.1. References: Web Services Description Language (WSDL) 1.1
2001-05-02	XML Schema	W3C Recommendation	XML Schema 1.0 became a W3C Recommendation. The document status is listed as W3C Recommendation 2 May 2001. ⇒ The type system referenced by WSDL was formally standardized at this point. The ability of WSDL descriptions to be machine-readable is due to the existence of a separate document that standardizes the meaning of types. ⚠ This dependency is later replicated when OpenAPI connects to JSON Schema. The description format cannot stand alone and always requires a separate specification that defines types. References: XML Schema Part 1: Structures

2003-2009 - The Recommendations Land, and the Working Group Closes

During this period, both SOAP and WSDL became official W3C Recommendations. Simultaneously, the working group that created them was dissolved. ⛔ These two developments are not contradictory. A later section elaborates on this point.

Date	Family	Type	Summary
2003-06-24	SOAP	W3C Recommendation	SOAP 1.2 became a W3C Recommendation. The title was SOAP Version 1.2 Part 1: Messaging Framework, and the status was listed as W3C Recommendation 24 June 2003. ⇒ This marked the first time that SOAP received a recommendation from W3C. It took three years from the SOAP 1.1 Note. ⚠ This version itself states its relationship to previous versions. The document states, SOAP Version 1.2 supercedes all previous versions of SOAP, including SOAP Version 1.1 ⛔ The spelling is the original's. Quotations have not been altered. References: SOAP Version 1.2 Part 1: Messaging Framework
2006-07	JSON	RFC	The media type for JSON was registered as RFC 4627. The status was listed as Informational. ⇒ At this point, JSON was not a standard, but rather a report describing a particular format being used. Informational RFCs do not represent a standard agreed upon by the IETF. ⚠ The transition from XML to JSON was not completed by this single document. It would take eleven years for it to be formally established as a standard. References: RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON)
2007-04-27	SOAP	W3C Recommendation	The second edition of SOAP 1.2 was released as a W3C Recommendation. The title was SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), and the status was listed as W3C Recommendation 27 April 2007. This edition incorporates errata accumulated since the first edition, replacing the original. ⛔ This row is particularly important for this article because it is the current version as of the verification date. As of September 11, 2026, the W3C page still lists this edition as a Recommendation. ⇒ This confirms that SOAP has not been withdrawn. The specific wording is placed in a later section of this timeline. References: SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
2007-06-26	WSDL	W3C Recommendation	WSDL 2.0 became a W3C Recommendation. The title was Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, and the publication date was 2007-06-26. ⚠ The version number increased, but this article does not treat in numbers how much either 1.1 or 2.0 was used. ⇒ What can be verified is that both WSDL 1.1 (as a Note) and WSDL 2.0 (as a Recommendation) remain unchanged and have not been withdrawn. References: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language
2008-07-07	Protocol Buffers	Open sourced	Google open-sourced Protocol Buffers. The announcement title was Protocol Buffers: Google's Data Interchange Format, and the publication date was 2008-07-07. ⇒ This marked the point at which the practice of writing a schema first and then generating code became publicly available. While the concept of schema-first is the same as WSDL, the resulting wire format is binary rather than XML. ⚠ At this point, only the message format was released. The calling procedure was not included. It would take seven years for the associated RPC framework to be released. References: Protocol Buffers: Google's Data Interchange Format
2009-07-10	SOAP	WG closed	The W3C closed the XML Protocol Working Group. The W3C Web Services page states, 2009-07-10 : The XML Schema Patterns for Databinding Working Group, the Web Services Choreography Working Group and the XML Protocol Working Group were closed. ⛔ It was the Working Group that was closed, not the specification itself. The XML Protocol Working Group was the group that created SOAP 1.2. ⇒ Even though the Working Group was closed, the Recommendation it produced remains a Recommendation. This distinction is a point that is most often simplified in secondary articles. References: Web Services @ W3C

2010-2014 - JSON Takes the Wire, and the Description Comes Back

During this period, a machine-readable interface description reappeared, though under a different name. It emerged not within SOAP, but within HTTP APIs, which were initially intended to operate without descriptions.

Date	Family	Type	Summary
2010-03-26	JSON-RPC	Spec release	The JSON-RPC 2.0 specification was released. The specification page notes Origin Date: 2010-03-26 (based on the 2009-05-24 version) and Updated: 2013-01-04. ⇒ This is a rewrite of the same concepts as XML-RPC, but using JSON. The message format consists of a single request-response exchange, including the method name, params, and an id. ⚠ This row appears in this article not only for historical reasons, but because the Model Context Protocol, published 14 years later, uses this specification as the foundation for its message format. References: JSON-RPC 2.0 Specification
2011-08-10	OpenAPI	Spec release	The first version of the Swagger specification was released. The OpenAPI Specification's own Revision History records 1.0, 2011-08-10, and First release of the Swagger Specification. ⇒ This marks the second time a machine-readable interface description appeared. The first was WSDL in 2001. ⛔ However, the origins are different. WSDL defined the message format and the transfer procedure itself, while Swagger defines neither and only describes an HTTP API. ⇒ This difference is one reason why this format has proven so durable. References: OpenAPI Specification v3.2.0
2012	GraphQL	Spec release	GraphQL was created within Facebook. The GraphQL specification's Introduction states, GraphQL was originally created in 2012 and the development of this open standard started in 2015. ⚠ This row only provides the year. This is because the specification itself only mentions the year; this article does not provide month and day details. ⛔ At this point, it was not a publicly released specification. A public draft of the specification would not be released for another three years. ⇒ This row appears because even before the public release, it was already in production use inside the company, a fact that helps explain the later form of the specification. References: GraphQL September 2025 Edition
2014-03-14	OpenAPI	Spec release	Swagger 1.2 was formally released as a documented specification. The Revision History states 1.2, 2014-03-14, and Initial release of the formal document. ⇒ Previously, the description format had been distributed alongside the implementation; now it became an independent specification document. This row appears because the change was not about adding new features, but about establishing a new role for the document itself. References: OpenAPI Specification v3.2.0
2014-06	HTTP	RFC	The definition of HTTP/1.1 was split into six separate RFCs: RFC 7230 through RFC 7235, obsoleting RFC 2616. For example, RFC 7231 is titled Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and is recorded as Obsoletes RFC 2616. ⇒ A single, 15-year-old RFC was divided into separate roles. The purpose of the split was to separate version-independent semantics from version-specific message formats. ⚠ This separation would later enable HTTP/2 and HTTP/3 to be built upon the same semantics. References: RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
2014-09-08	OpenAPI	Spec release	Swagger 2.0 was released. The Revision History states 2.0, 2014-09-08, and Release of Swagger 2.0. ⇒ This version became the first widely adopted specification format. Previously, the listing and declaration were separate; now they were combined into a single document, and it was possible to write it in YAML. ⚠ This version would have two subsequent dates. One was the public release date, and the other was the date it was donated to a different organization. The donation occurred in 2015. References: OpenAPI Specification v3.2.0

2015-2017 - Three Conventions Arrive in Three Years

Most of the design paradigms currently in use emerged during these three years. gRPC, GraphQL, and OpenAPI, driven by distinct motivations, appeared almost simultaneously.

Date	Family	Type	Summary
2015-02-26	gRPC	Open sourced	Google open-sourced gRPC. The announcement, titled Introducing gRPC, a new open source HTTP/2 RPC Framework was released on February 26, 2015, and stated, Today, we are open sourcing gRPC, a brand new framework for handling remote procedure calls. ⇒ This release included not only the format of the messages but also the procedures for making calls. The official documentation states, gRPC can use protocol buffers as both its Interface Definition Language (IDL) and as its underlying message interchange format. ⛔ This marks the return of the term IDL to official documentation after 14 years. The one that carried the same role before was WSDL. References: Introducing gRPC, a new open source HTTP/2 RPC Framework
2015-05	HTTP	RFC	HTTP/2 was published as RFC 7540. It allows multiple interactions to be transmitted simultaneously over a single connection, and headers are compressed. ⇒ This foundation enables gRPC to handle bidirectional streams. ⚠ This RFC was later obsoleted. It has been replaced by RFC 9113 (2022). ⛔ However, the HTTP/2 protocol itself has not been deprecated. Only the document defining it has been replaced. References: RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
2015-07-02	GraphQL	Spec release	The GraphQL specification was first publicly released. The distribution site lists this version as July 2015 and records the date as Thu, Jul 2, 2015 ⇒ This marked the public availability of a design that had been used internally for three years. ⛔ This specification does not define the format of messages. Instead, it defines a query language, a type system, and the procedures for execution. ⇒ Therefore, GraphQL is not a specification for an electronic envelope like SOAP, nor is it an architectural style like REST. It is similar to WSDL in that it has a type system, and similar to REST in that it does not specify the procedures for transmission. References: GraphQL July 2015 Edition
2015-11-05	OpenAPI	Announcement	The launch of the OpenAPI Initiative was announced. The announcement, presented by Linux Foundation as a collaborative effort, also revealed that SmartBear would donate the Swagger specification. The announcement stated that the initiative's purpose is to create a vendor neutral, portable and open specification ⚠ The announcement also mentions the history of Swagger. It states, Swagger was created in 2010 and offered under an open source license a year later ⛔ This date is not the date on which the donation was completed. The completion of the donation is recorded on a separate date. References: New Collaborative Project to Extend Swagger Specification for Building Connected Applications and Services
2015-12-31	OpenAPI	Donated	Swagger 2.0 was donated to the OpenAPI Initiative. The OpenAPI Specification's revision history records 2.0 2015-12-31 and Donation of Swagger 2.0 to the OpenAPI Initiative ⇒ The same version, 2.0, has two rows: one for the release date and one for the donation date. This is because the announcement and the legal transfer occurred on different dates. ⚠ Some secondary articles may combine these two dates into a single row. References: OpenAPI Specification v3.2.0
2016-08-24	gRPC	Spec release	gRPC 1.0 was released. The announcement, titled gRPC: a true internet-scale RPC framework is now 1.0 and ready for production deployments was released on August 24, 2016. ⇒ This release declared the stability of the API and the availability of implementations in multiple languages. ⚠ This is not the publication of a specification document. With gRPC, the implementation and protocol definition are released together. ⇒ This difference would later become relevant in discussions about standardization. References: gRPC: a true internet-scale RPC framework is now 1.0 and ready for production deployments
2017-02-16	gRPC	CNCF	gRPC was accepted into the CNCF. The CNCF project page states, gRPC was accepted to CNCF on February 16, 2017 at the Incubating maturity level. ⚠ This statement refers to the maturity level at the time of acceptance, not its current maturity level. The current maturity level can be found on a separate page. ⛔ When the CNCF project listing is viewed on September 11, 2026, gRPC is listed under Our Incubating Projects. ⇒ Despite being accepted over nine years ago, its maturity level has not changed. This does not indicate neglect or immaturity; the term is used in a specific way, as explained in a later section. References: gRPC - Cloud Native Computing Foundation / Graduated and Incubating Projects - CNCF
2017-07-26	OpenAPI	Spec release	OpenAPI Specification 3.0.0 was released. The announcement, titled The OAI Announces the OpenAPI Specification 3.0.0 was released on July 26, 2017. ⇒ This marked the first major release of the specification, previously known as Swagger. ⚠ Only the specification itself changed names, not the tools. The name Swagger is still used for tools. This article does not address the tools. References: The OAI Announces the OpenAPI Specification 3.0.0
2017-09-26	GraphQL	Relicensed	The license for the GraphQL specification was changed. The announcement, titled Relicensing the GraphQL specification stated, Today we're relicensing the GraphQL specification under the Open Web Foundation Agreement (OWFa) v1.0. ⇒ This moved the handling of the specification's rights from a corporate copyright notice to an agreement premised on standardization. ⛔ This article does not judge the merits of this change. It simply records the date on which the license was changed. ⚠ This change is a prerequisite for the transfer of management to a different entity, which will begin the following year. References: Relicensing the GraphQL specification
2017-12	JSON	RFC	JSON became an Internet Standard with the publication of RFC 8259. This RFC assigned the standard the number STD 90 and obsoleted RFC 7159. ⇒ The format, initially registered as Informational in 2006, reached the highest level the IETF has after eleven years. ⚠ Pay attention to the order of events. APIs and protocols that use JSON were already widely used before this date. ⇒ Standardization followed widespread adoption, rather than the other way around. References: RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format

2018-2022 - Custody Moves to Foundations, and HTTP Becomes a Standard

What moved during this period was not the content of the specifications but who holds them. Simultaneously, HTTP, which had been in use for over 20 years, finally became an Internet Standard.

Date	Family	Type	Summary
2018-06-10	GraphQL	Spec release	The June 2018 version of GraphQL was released. The distribution source records the date as Sun, Jun 10, 2018. ⇒ This was the first version after the license was switched to OWFa 1.0. The version now included a cover page, and the legal status was documented in the document itself. References: GraphQL June 2018 Edition
2018-11-06	GraphQL	Foundation	The Linux Foundation announced its intention to form a new foundation to support GraphQL. The announcement was titled The Linux Foundation Announces Intent to Form New Foundation to Support GraphQL. ⛔ However, a foundation was not actually formed on this date. The announcement was simply an expression of intent. ⇒ While many secondary articles state this date as the foundation's founding date, the GraphQL specification itself lists a different year. The actual formation occurred later. ⚠ This article splits the two into separate rows because that misunderstanding does occur. References: The Linux Foundation Announces Intent to Form New Foundation to Support GraphQL
2019-03-12	GraphQL	Foundation	A collaboration between the GraphQL Foundation and the Joint Development Foundation was announced. The announcement, titled The GraphQL Foundation Announces Collaboration with the Joint Development Foundation to Drive Open Source and Open Standards, was dated 2019-03-12. ⇒ This marked the establishment of the framework for creating the specification. The announcement stated GraphQL is the first Linux Foundation project to benefit from the JDF and Linux Foundation collaboration. ⚠ This year aligns with the specification's own description. The GraphQL specification's Introduction states, The GraphQL Foundation was formed in 2019 and It is a deliverable of the GraphQL Specification Project, established in 2019 with the Joint Development Foundation. References: The GraphQL Foundation Announces Collaboration with the Joint Development Foundation to Drive Open Source and Open Standards
2021-02-15	OpenAPI	Spec release	The OpenAPI Specification 3.1.0 was released. The document indicates the version as Version 3.1.0 and the date as 15 February 2021. ⛔ This version is the closest to the core focus of this article. Version 3.1.0 reconnected the definition of types to JSON Schema, and the document states Data types in the OAS are based on the types supported by the JSON Schema Specification Draft 2020-12, defining a Schema Object as its superset. ⇒ This echoes the relationship between WSDL and XML Schema in 2001, but two decades later. The format itself cannot stand alone and requires a separate specification to define types. ⚠ This pattern is repeated in the next generation. References: OpenAPI Specification v3.1.0
2021-10-26	GraphQL	Spec release	The October 2021 version of GraphQL was released. The distribution source records the date as Tue, Oct 26, 2021. ⇒ This was the first version after the foundation's framework was established. References: GraphQL October 2021 Edition
2022-06	HTTP	RFC	The semantics of HTTP became an Internet Standard as RFC 9110. This RFC, designated STD 97, obsoletes several other RFCs, including RFC 7231. ⇒ This marks the first time, after 23 years since RFC 2616 was published in 1999, that HTTP reached the highest level the IETF has. ⛔ This is a critical point for this article. The foundation upon which REST, as a design style, depends became a standard 22 years after the publication of the REST dissertation. ⇒ The standardization of a design style and the standardization of the protocol that carries it operate on separate clocks. References: RFC 9110 - HTTP Semantics
2022-06	HTTP	RFC	The definition of HTTP/2 was replaced by RFC 9113, obsoleting RFC 7540 and RFC 8740. ⇒ While the 2015 document was replaced, the protocol itself continued to operate under the same name. ⚠ At the IETF, marking a document obsolete does not mean the technology is no longer in use. It means that the definitive document defining the technology has been superseded by a different document. References: RFC 9113 - HTTP/2
2022-06	HTTP	RFC	HTTP/3 was published as RFC 9114, currently designated as a Proposed Standard and not yet marked as obsolete. ⇒ This resulted in a situation where three versions of HTTP, 1.1, 2, and 3, simultaneously exist as current versions. All three versions share the same semantics as defined in RFC 9110, but differ only in the way data is transmitted. ⛔ A new version appeared, and the previous versions were not withdrawn. This mirrors the generational shift in design paradigms that this article addresses. References: RFC 9114 - HTTP/3

2024-2025 - Machine-Readable Schemas Are Required Again

During this period, the requirement for a machine-readable interface description was raised for the third time. This requirement is not being imposed by humans, but rather by language models that are now initiating the requests.

Date	Family	Type	Summary
2024-10-24	OpenAPI	Spec release	The OpenAPI Initiative released patch versions for both the 3.0 and 3.1 series on the same day. The Revision History shows two rows: 3.1.1 2024-10-24 and 3.0.4 2024-10-24. ⇒ Even after a new series is released, the older series continues to be maintained. ⛔ This single row highlights the core argument of this article. While version 3.1 was released in 2021, the 3.0 series was still receiving updates in 2024. ⇒ The introduction of a new version does not mean the end of the previous one. References: OpenAPI Specification v3.2.0
2024-11-25	MCP	Announcement	The Model Context Protocol was released. The announcement, titled Introducing the Model Context Protocol, was published on 2024-11-25. ⇒ This protocol carries tool definitions as machine-readable schemas. It is built upon JSON-RPC 2.0. ⛔ This article stops the lineage here. Existing publications already cover version-specific changes and the lineage from function calling onwards. ⇒ This article only records the fact that the demand for a machine-readable interface description rose for a third time. References: Introducing the Model Context Protocol
2025-09-03	GraphQL	Spec release	The September 2025 edition of GraphQL was released. The distribution site lists this version as Latest Release and records the date as Wed, Sep 3, 2025. ⚠ Verification was performed on 2026-09-11. Because version information can change, it is important to include the verification date when referencing it. ⇒ The same listing also includes a Working Draft dated Thu, Jun 4, 2026. References: GraphQL September 2025 Edition
2025-09-19	OpenAPI	Spec release	OpenAPI Specification 3.2.0 was released. The document displays the version as Version 3.2.0 and the date as 19 September 2025. ⚠ On the same day, a patch version for the 3.1 series, 3.1.2, was also released. The Revision History shows rows for 3.2.0 2025-09-19 and 3.1.2 2025-09-19. ⇒ On the same day a new version is released, a maintenance release for a previous series is also made available. ⚠ The 3.2 series has since received a patch release. The same table shows 3.2.1 2026-09-10, which is the most recent row as of the verification date. ⚠ Verification was performed on 2026-09-11. References: OpenAPI Specification v3.2.0

What Each Generation Dropped and Inherited

The One Thing That Left and Came Back

Within this lineage, there is exactly one element that clearly left and then clearly returned. It is the machine-readable interface description.

Looking at the sequence, it unfolded as follows: ⇒ In 2001, WSDL brought it in. WSDL made it possible to write, in a format machines could read, what operations existed, what types of argument they took, and what types they returned. ⇒ REST does not have this. Fielding's dissertation defines an architectural style, not a specific description format. ⇒ In 2011, Swagger brought it back in a different form. Unlike WSDL, it didn't define message formats or transfer procedures; instead, it described HTTP APIs. ⇒ In 2021, OpenAPI 3.1.0 connected to JSON Schema. This mirrored the relationship that WSDL previously had with XML Schema. ⇒ A protocol published in 2024 began carrying tool definitions as machine-readable schemas.

⛔ This cycle isn't about which generation is superior. It simply demonstrates the fact that if you abandon machine-readable interface descriptions, you end up rebuilding them elsewhere.

Generation by Generation

Here's a table outlining what each generation discarded and what it inherited or recovered. ⚠ There's a difference between what was discarded and what was lost. The meaning of this distinction will be explained in the next section.

Generation	What It Dropped	What It Inherited or Recovered
XML-RPC (1999)	A separate document for describing the interface. The specification only defines the format of the message and a set of data types.	HTTP POST as a means of transporting messages. Data types are limited to scalars, structures, and arrays.
SOAP with WSDL (2000-2001)	⛔ Nothing was discarded in this generation. SOAP and WSDL performed additions rather than replacements.	A machine-readable interface description and a standardized type system. WSDL describes operations and data types, while XML Schema defines the meaning of those types.
REST (2000)	Message envelopes, a framework that treats calls as procedures, and machine-readable interface descriptions.	Leveraging the existing semantics of HTTP as a uniform interface. The dissertation mentions caching as one of the constraints.
OpenAPI, formerly Swagger (2011-)	The freedom to define message formats and transmission procedures.	Returned machine-readable interface descriptions to HTTP APIs. Starting with version 3.1.0, it connects to JSON Schema.
gRPC with Protocol Buffers (2015)	The option of not having a separate description document. You cannot define a service without a .proto file.	A schema-first IDL, and the code generated from it. The same format is also used for serialization. Additionally, it carries four kinds of call over HTTP/2.
GraphQL (2015)	The assumption that the service determines the shape of the response.	A type system and introspection. The authority to determine the shape of the response was shifted to the client. The specification explicitly states this as a design principle.

What the Specifications Themselves Say About Their Own Role

⚠ The table above is this article's own arrangement. The primary sources state in their own words how each specification describes its own role.

The Abstract for WSDL 1.1 describes the subject of its description as follows:

WSDL is an XML format for describing network services as a set of endpoints operating on messages
containing either document-oriented or procedure-oriented information. The operations and messages
are described abstractly, and then bound to a concrete network protocol and message format to define
an endpoint.

The OpenAPI Specification 3.2.0 similarly describes the same role in relation to HTTP APIs.

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface
description for HTTP APIs, which allows both humans and computers to discover and understand the
capabilities of a service without requiring access to source code, additional documentation, or
inspection of network traffic.

⇒ These two statements essentially say the same thing. One originates from the world of XML in 2001, while the other comes from the world of HTTP in 2025.

The official gRPC documentation explicitly names the format of the description.

gRPC can use protocol buffers as both its Interface Definition Language (IDL) and as its underlying
message interchange format.

⚠ From this point on, two statements describe the same trade-off from opposite directions. Fielding's dissertation explicitly states what a uniform interface is obtained in exchange for.

The trade-off, though, is that a uniform interface degrades efficiency, since information is
transferred in a standardized form rather than one which is specific to an application's needs.

The GraphQL specification outlines who determines the shape of the response as a design principle.

Client-specified response: Through its type system, a GraphQL service publishes the capabilities
that its clients are allowed to consume. It is the client that is responsible for specifying exactly
how it will consume those published capabilities. These requests are specified at field-level
granularity. In the majority of client-server applications written without GraphQL, the service
determines the shape of data returned from its various endpoints. A GraphQL response, on the other
hand, contains exactly what a client asks for and no more.

⇒ These two statements describe the ends of the same axis. REST accepted returning responses in a standardized format rather than application-specific formats as a trade-off for a uniform interface. GraphQL, on the other hand, places returning only what the client requests as a design principle. ⛔ This is not a question of which one is right. Both are choosing from the same trade-off, from opposite ends.

The specification for XML-RPC describes its own role in a single sentence.

XML-RPC is a Remote Procedure Calling protocol that works over the Internet.

⇒ When you list these six together, you can see what has been inherited and what has been replaced. The role of describing interfaces in a machine-readable format has persisted, albeit with different names and formats. What has been replaced is the purpose for which that description is used.

References: Web Services Description Language (WSDL) 1.1 / OpenAPI Specification v3.2.0 / Introduction to gRPC / Architectural Styles and the Design of Network-based Software Architectures / GraphQL September 2025 Edition / XML-RPC Specification

The Three Things That Never Left

When you chase after what has been discarded, things that were never discarded come into view. There are three.

1. It is HTTP. XML-RPC uses HTTP's POST method, SOAP places an envelope on top of it, REST makes the semantics of HTTP itself the contract, and gRPC chose HTTP/2. The GraphQL specification does not define transport. ⛔ However, this does not mean it specifies an alternative. ⇒ No generation names a transport other than HTTP.

1. It is a dependency on another specification to define types. WSDL requires XML Schema, gRPC requires Protocol Buffers, and OpenAPI 3.1.0 requires JSON Schema. ⛔ A descriptive format alone cannot stand on its own. A separate document is always required to define the meaning of the types.

1. It is the assumption that machines do the reading. WSDL's Abstract describes the subject of its description as a set of network service endpoints, defining it as a format for machines to process. The opening of OpenAPI names its readers explicitly as both humans and computers. ⇒ The requirement that a machine be able to read it has not been withdrawn in any generation.

⚠ Regarding the first point, do not confuse what is not specified with what was chosen as an alternative. The GraphQL specification uses similar wording regarding message formats.

GraphQL does not require a specific serialization format. However, clients should use a
serialization format that supports the major primitives in the GraphQL response.

JSON is the most common serialization format for GraphQL. Though as mentioned above, GraphQL does
not require a specific serialization format.

⇒ It is important to distinguish between what a specification does not require and what is actually being used. This article keeps that distinction too.

⚠ Only the layers built upon these three have changed. The message format, the language of the description, the calling procedure, and who decides the shape of the response. ⇒ If you read the lineage as a chain of replacements, these three become obscured.

References: GraphQL September 2025 Edition

Why "Dropped" Is Not the Same as "Lost"

REST's lack of a machine-readable interface description is not an omission. Fielding's dissertation defined an architectural style, and the format of the description itself was never within that scope. ⛔ This article does not discuss how this was perceived at the time. There is no primary source to support such an account.

⛔ However, just because something was discarded doesn't mean it was deemed unnecessary. When a description became necessary, it was recreated under a different name. Swagger, released in 2011, is one example, and the schema that carries tool definitions from 2024 onwards is another.

⚠ What came back is not the same thing, and that is worth noticing.

• WSDL was integrated with the message. The description determined the form of the call.
• OpenAPI is independent of the message. It simply describes HTTP APIs, without defining the message format or the transfer process.
• ⇒ Because of this difference, OpenAPI is not a revival of WSDL. It fulfills the same role, but in a different way.

⛔ This article does not write this round trip up as progress or as regression. It can only state the fact that the same role has been required three times, and each time it has been fulfilled using a different format.

Current Overview of the API Design Paradigms in Use Today

Where Each Specification Stands Today

Verification date: 2026-09-11. The status of each specification is indicated as reflected in the primary sources.

Specification	Status as of the verification date	Where that status is stated
XML-RPC	The specification continues to be distributed. It is not under the management of any standardization body.	xmlrpc.com specification page
SOAP 1.1	W3C Note. It was never a Recommendation, from the outset.	W3C TR page status
SOAP 1.2	W3C Recommendation. The second edition, dated April 27, 2007, is the current one.	W3C TR page status
WSDL 1.1	W3C Note.	W3C TR page status
WSDL 2.0	W3C Recommendation.	W3C TR page status
REST	Not a document from any standardization body. It is defined as an architectural style in a doctoral dissertation.	Chapter 5 of Fielding's dissertation
HTTP	RFC 9110 is an Internet Standard (STD 97). Versions 1.1, 2, and 3 are current at the same time.	IETF datatracker
gRPC	CNCF Incubating. Accepted on February 16, 2017.	CNCF project page and project listing
GraphQL	The latest version is September 2025. A separate Working Draft also exists.	spec.graphql.org version list
OpenAPI	The latest version is 3.2.1 (2026-09-10). Versions in the 3.1 and 3.0 series are also being maintained.	spec.openapis.org Revision History

⛔ This table contains no rows indicating deprecation or obsolescence. As far as can be verified from the primary sources, none of these specifications have been withdrawn.

References: SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) / Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language / RFC 9110 - HTTP Semantics / gRPC - Cloud Native Computing Foundation / GraphQL Specification Versions

Why None of These Specifications Were Rescinded

The summary that REST replaced SOAP cannot be verified against the primary sources. What can be confirmed is that separate specifications were each published.

The status section of SOAP 1.1 states that this document carried no endorsement from W3C from the outset.

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by
W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial
control over the preparation of this Note. This document is a work in progress and may be updated,
replaced, or rendered obsolete by other documents at any time.

⇒ In other words, SOAP 1.1 was not a standard that was withdrawn. It was never a standard to begin with. The status section for WSDL 1.1 contains the exact same wording.

In contrast, the status section of SOAP 1.2 states the following, as of the verification date.

It is a stable document and may be used as reference material or cited from another document. W3C's
role in making the Recommendation is to draw attention to the specification and to promote its
widespread deployment.

⛔ There is no mention of termination or deprecation here. The second edition, published in 2007, remains available in the same location, still listed as a Recommendation.

⇒ When secondary articles state that SOAP has fallen out of use, their basis is the state of adoption, not the standardization status. This article does not treat the state of adoption in numbers. What it can treat is what the documents themselves state.

⚠ Naturally, an objection may arise. The objection is that perhaps W3C simply doesn't retire specifications. ⛔ However, that argument does not hold. W3C defines its own statuses for retiring specifications, and has simply not applied them to SOAP and WSDL. This will be demonstrated in the next section.

References: Simple Object Access Protocol (SOAP) 1.1 / Web Services Description Language (WSDL) 1.1 / SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)

What a Closed Working Group Does Not Do

On July 10, 2009, the XML Protocol Working Group, which created SOAP 1.2, was closed. The W3C's Web Services page states the following:

2009-07-10 : The XML Schema Patterns for Databinding Working Group, the Web Services Choreography
Working Group and the XML Protocol Working Group were closed.

⛔ It is important to distinguish between the closure of a working group and the withdrawal of a Recommendation produced by that working group.

• The closure of a working group means that the organization responsible for revising the specification has been dissolved.
• The withdrawal of a Recommendation means that the W3C no longer recommends that document.

⇒ The former occurred in 2009. As of the verification date, the latter has not occurred. Treating these two events as equivalent would suggest that the W3C has deprecated SOAP. ⚠ However, the W3C's Technical Report (TR) page still lists SOAP 1.2 as a Recommendation.

References: Web Services @ W3C

Both Bodies Can Retire a Document, and Only One of Them Did

⛔ First, one thing has to be confirmed. The W3C has a mechanism for retiring specifications. The explanation that SOAP remains only because there is no means of withdrawal is not accurate.

The W3C's Process Document outlines the procedure for retiring a Recommendation in a section titled Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation. The W3C's page listing the different types of published documents defines the resulting status as follows:

A Superseded Recommendation is a specification that has been replaced by a newer version that W3C
recommends for new adoption. Software SHOULD implement the newer versions.

An Obsolete Recommendation is a specification that W3C has determined lacks sufficient market
relevance to continue recommending it for implementation. Software MAY have implemented these
specifications.

A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes
there is no reasonable prospect of it being restored to Recommendation status. Software SHOULD NOT
implement these specifications.

⇒ There are three statuses for retiring a document. Furthermore, the full text of both the SOAP 1.2 and WSDL 2.0 Technical Reports was retrieved and examined on the verification date, 2026-09-11. The wording of these three statuses appears on neither page, not once. Both are displayed as W3C Recommendation. ⚠ There is only one potentially ambiguous term. The SOAP 1.2 page uses the word Obsoletes once, but this appears in the references section, describing how the IETF's RFC 3986 replaced RFC 2396 and RFC 2732; it does not refer to the status of SOAP itself.

⇒ In other words, the W3C possesses the means to perform this action, but is not using them for these two specifications.

On the other hand, the IETF frequently performs similar operations. RFCs carry the Obsoletes and Obsoleted by relationships as metadata, as demonstrated by the examples in the timeline presented in this article.

Document	Relationship	Recorded on datatracker
RFC 2616	Replaced by RFCs 7230 through 7235	Obsoleted by
RFC 7231	Replaced by RFC 9110	Obsoleted by
RFC 7540	Replaced by RFC 9113	Obsoleted by
RFC 4627	Replaced by RFC 7159, and subsequently by RFC 8259	Obsoleted by
RFC 9114	Not yet replaced, as of the verification date	None

⛔ A different misreading is prone to occur here. The fact that an RFC becomes obsolete does not mean that the technology it describes is no longer in use. ⇒ HTTP/1.1 is still operational. The only change was the identification of which document serves as the definitive specification.

⇒ Comparing the two bodies, it becomes clear that the difference isn't the presence or absence of a specific mechanism. The IETF replaced the defining documents for HTTP/1.1 twice and once for HTTP/2, but the technology itself remained. Meanwhile, the W3C did not replace, mark as obsolete, or rescind anything related to SOAP or WSDL. ⚠ In both cases, there is no record of the technology disappearing.

What Each Status Label Actually Asserts

⚠ The meaning of each status label varies depending on the organization. Rounding all of them off into the single word standard makes the comparison itself impossible.

Label	Body	What the label asserts
W3C Note	W3C	This indicates a document published for discussion purposes. The status sections of SOAP 1.1 and WSDL 1.1 state plainly that W3C does not endorse them.
W3C Recommendation	W3C	This signifies a specification that has been through a consensus process and carries an endorsement from W3C. The ones whose current status this article verified are SOAP 1.2 and WSDL 2.0.
Rescinded Recommendation	W3C	This indicates a status where W3C has withdrawn its endorsement and sees no reasonable prospect of a return to that status. It is not attached to SOAP 1.2 or WSDL 2.0, the two whose status this article verified.
Proposed Standard	IETF	This refers to an RFC that is undergoing the standardization process. An example is RFC 9114 for HTTP/3.
Internet Standard	IETF	This is the highest status the IETF has. Examples include RFC 9110 for HTTP semantics and RFC 8259 for JSON.
Obsoleted by	IETF	This describes a relationship where another RFC replaces the specified RFC. It does not necessarily indicate the end of a technology.
Incubating	CNCF	This category expresses a position inside the foundation. It does not indicate an evaluation of whether the technology is ready for production use.

⛔ This table does not contain any rows that indicate a technology is not being used. Each label simply describes the relationship between a document and an organization. ⇒ There is no terminology within this vocabulary that describes the actual usage of a technology.

References: Types of documents W3C publishes / World Wide Web Consortium Process Document / RFC 9114 - HTTP/3 / gRPC - Cloud Native Computing Foundation

Reading "Incubating" Without Rounding It Off

gRPC was accepted into the CNCF on February 16, 2017, and as of the verification date its maturity level remains Incubating.

⚠ These two points are verified on separate pages. The project page states the maturity level at the time of acceptance, while the current maturity level is indicated in the heading of the project listing. ⛔ Writing the current status from the acceptance wording alone goes wrong if the project was promoted in the meantime.

⛔ Interpreting this term as meaning not yet ready for production would be inaccurate. The CNCF's maturity levels are not an assessment of whether the technology functions correctly; rather, they express a position inside the foundation. ⇒ This article does not speculate on the reasons why the level has remained Incubating for over nine years. No CNCF document that states those reasons could be verified.

⚠ Only two points can be confirmed. First, the acceptance date was February 16, 2017. Second, as of the verification date, the project is listed under Our Incubating Projects on the project listing. ⇒ This article will not state anything beyond these two points.

References: gRPC - Cloud Native Computing Foundation / Graduated and Incubating Projects - CNCF

Where the Current Wave Sits

The approach to defining tools that emerged from 2024 onwards is the third time this has happened in the lineage of this article.

• The first was WSDL in 2001, which defined operations and types in a machine-readable format.
• The second was Swagger and OpenAPI, starting in 2011, which shifted back to describing HTTP APIs.
• The third is the present. Tool definitions are now carried as machine-readable schemas over a protocol.

⛔ This article will not proceed further. Version-by-version changes to the Model Context Protocol, the lineage from function calling, and the relationship with Agent2Agent are all subjects held by existing publications. ⇒ This article only records the fact that the same role has been requested three times.

⚠ This article does not predict whether the third time will replace the first or the second. What this lineage has demonstrated so far is not replacement, but rather overlap.

Frequently Asked Questions about API Design Paradigm History

Did REST replace SOAP?

No. What can be confirmed from the primary sources is simply that separate specifications were each published. SOAP 1.2 remains a W3C Recommendation and has not been withdrawn. ⚠ Furthermore, the timeline does not reflect a straightforward replacement sequence. The W3C Note for SOAP 1.1 was dated May 8, 2000, and the dissertation that defined REST was also published in the same year, 2000.

Is SOAP deprecated or withdrawn?

No. The W3C TR page lists SOAP 1.2 as a Recommendation as of the verification date of 2026-09-11. The current version is the second edition, dated 2007-04-27. ⚠ While the working group that created SOAP 1.2 was closed on 2009-07-10, this does not constitute a withdrawal of the specification.

Does W3C even have a way to retire a Recommendation?

Yes. The W3C's Process Document includes a section titled Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation, and defines three possible final states: Superseded Recommendation, Obsolete Recommendation, and Rescinded Recommendation. ⛔ As of the verification date, neither the SOAP 1.2 nor the WSDL 2.0 Technical Reports (TR) pages mention any of these three states.

Why is WSDL 1.1 only a W3C Note when WSDL 2.0 is a Recommendation?

The difference lies in the types of documents the W3C produces; Note and Recommendation are distinct categories. WSDL 1.1 was published as a Note on March 15, 2001, and its status section states plainly that the W3C does not endorse it. WSDL 2.0, on the other hand, became a Recommendation on June 26, 2007. ⛔ This article does not present numerical data on which version is more commonly used in practice.

Did OpenAPI reinvent WSDL?

Both serve the same role, but in a different way. Both describe operations and data types in a machine-readable format. ⛔ However, WSDL defines both the message format and the transfer procedures, while OpenAPI simply describes HTTP APIs. This difference means that OpenAPI does not define message formats itself.

Is gRPC still incubating at CNCF, and does that mean it is immature?

As of the verification date, gRPC remains at the Incubating maturity level. The CNCF project page states that it was accepted into the Incubating program on February 16, 2017, and is listed under the heading Our Incubating Projects. ⛔ This designation reflects the project's position inside the foundation and is not an evaluation of its readiness for production use. This article does not attempt to explain why the project has remained at this maturity level for over nine years.

When was the GraphQL Foundation formed?

The GraphQL specification itself states that the GraphQL Foundation was formed in 2019. ⚠ A November 6, 2018 announcement from the Linux Foundation indicated the intention to form a foundation. The framework was finalized with the announcement of a collaboration with the Joint Development Foundation on March 12, 2019, and the specification's introduction also lists this year. ⛔ While some secondary articles state that 2018 was the founding year, this contradicts the specification's own description.

Does GraphQL replace REST?

No. The two technologies serve different purposes. GraphQL's specifications define a query language, a type system, and the execution process, but do not specify how data is transmitted. REST is an architectural style and does not define a particular data format. ⛔ Determining which one to choose is outside the scope of this article.

Where does the Model Context Protocol fit into this lineage?

The third time a machine-readable interface description has been required. Published on November 25, 2024, it uses JSON-RPC 2.0 from 2010 as its foundation. ⛔ Version-by-version changes, and the lineage from function calling onwards, are held as subject matter by existing publications. This article does not assert a version number for this protocol.

Why does this timeline not say which paradigm to use?

The choice of paradigm depends on the specific problem you're addressing and the existing assets you have. This article can only track which documents were published on which dates and what their current status is. ⛔ This article does not include figures such as adoption rates or market share, as these cannot be reliably verified using primary sources.

Summary

This article presents a timeline of API design paradigms, spanning 41 rows, starting with XML 1.0 on February 10, 1998, and ending with the OpenAPI Specification 3.2.0 as of September 19, 2025.

Three key observations can be drawn:

1. No generation has ended. SOAP 1.2 and WSDL 2.0 remain as W3C Recommendations. Three versions of HTTP are current at the same time. OpenAPI maintains three parallel series: 3.0, 3.1, and 3.2. ⇒ The release of a new specification does not mean the withdrawal of the previous one.

1. The machine-readable interface description left once and came back. WSDL brought it in during 2001, REST did not carry it, Swagger brought it back in a different form in 2011, and OpenAPI 3.1.0 reconnected it to JSON Schema in 2021. ⇒ And from 2024 onwards, the same role has been raised for a third time.

1. Standardization status and the state of adoption operate on different clocks. HTTP became an Internet Standard in 2022, 22 years after the publication of the REST dissertation. JSON became an Internet Standard in 2017, long after APIs utilizing JSON had become widespread.

⇒ When deciding whether to incorporate a new convention into existing APIs, the most recent version is not the relevant factor. Instead, it is crucial to understand what the convention accepts and what it does not, in relation to current conventions. ⛔ Furthermore, there is, at least from the perspective of the specifications themselves, no inherent assumption of replacement.

All information presented in this article was verified as of September 11, 2026. ⚠ The latest version of a specification, and the maturity level displayed by a foundation, are both subject to change. Always check the verification date when referencing this information.


References:
Tech Blog with curated related content