If you work with APIs today, it’s hard to imagine shipping a service without a machine-readable contract. The OpenAPI Specification (OAS) is now a default option for describing endpoints, parameters, authentication, and responses in a standardized way. But if you rewind to the Web’s earliest years—roughly 1990 through 1994—OpenAPI wasn’t even a concept yet, and “web API” wasn’t a mainstream phrase.

And still, that era quietly established the building blocks that later made OpenAPI possible. In the early Web, the “contract” lived in a small set of shared rules: the format of URLs, the basic semantics of HTTP requests, and the meaning of content types. Those standards didn’t describe APIs the way OpenAPI does, but they created something equally important: interoperability through a common vocabulary.

This chapter looks at how the birth of the Web and the first HTTP interfaces planted the seed for standardized API descriptions—and why the absence of a formal description format in 1990–1994 shaped the way API documentation evolved afterward.

1990–1991: A “Web API” Was Essentially a URL and a Method

The earliest Web interactions were intentionally simple. A client requested a resource by its address, and a server returned a representation. At the time, the interface that developers relied on looked like this:

• An identifier: a URL (or, more broadly, a URI concept) that pointed to something.
• An operation: a small set of request actions (early HTTP usage heavily centered on retrieval).
• A representation: the response body, often plain text or HTML, meant for a human to read.

In modern terms, that feels like a constrained, read-only API. But the key historical detail is that the interface was standardized enough that new clients and servers could be created independently and still communicate. Standardization in this period was less about “here’s a schema for every endpoint” and more about “here’s a universally understood way to ask for something on a network.”

That’s the first thread that leads to OpenAPI: once developers get accustomed to shared rules, they start expecting more of them—first for transport and identifiers, later for documentation and contracts.

1992–1993: As the Web Grows, “Interface Clarity” Becomes a Practical Problem

As adoption expanded—helped along by easier-to-use browsers and more publicly accessible servers—teams began to push beyond static documents. They wanted interactivity: search boxes, guestbooks, and dynamic content driven by server-side programs.

What’s interesting for API history is that this is when the Web started producing repeatable patterns that feel very “API-like,” even if they were primarily used for human-facing pages:

• Query strings became a de facto way to pass parameters to server logic.
• HTML forms created a standard input mechanism (field names, encoding expectations, and a target URL).
• Early server extensions and gateway mechanisms made it possible for a URL to map to a program, not just a file.

These interactions had a “contract,” but it was mostly implicit. If you knew the right parameter names and expected output format, you could integrate. If you didn’t, you were stuck reading prose documentation (if it existed) or guessing by trial and error.

This is a major point in the chronology of web APIs: the Web’s early success created a demand for dynamic interfaces, but the tooling for describing those interfaces wasn’t mature. The gap between “we can build it” and “others can reliably consume it” widened quickly.

1993–1994: MIME and Content Types Hint at “Self-Describing” Responses

One reason the Web could scale without a formal API description language was that it leaned on standardized metadata. In particular, content types (MIME types) gave clients a consistent way to interpret responses.

Even if a client didn’t understand the specific content inside a response, the server could label what it was sending. This pattern—metadata first, payload second—is deeply aligned with how APIs are documented today. OpenAPI doesn’t just list endpoints; it also describes media types, payload shapes, and encoding rules.

In the early 1990s, the Web was already moving in that direction by normalizing ideas like:

• “This is HTML” vs. “this is plain text” (and later, many other formats).
• Headers as contract clues—a place to put reusable meaning outside the body.
• Negotiation concepts—the idea that clients and servers can agree on representations, even if the implementation details differ.

From an API-history perspective, this is the moment standardized descriptions begin to take shape—not as a single file like an OpenAPI document, but as a distributed set of conventions that reduce guesswork.

1994 and the Standardization of URLs: A Foundational “API Description” Primitive

If you had to pick one artifact from 1990–1994 that most clearly supports the long arc toward standardized API descriptions, it’s the standardization work around URLs. A key milestone is the IETF RFC that documents URL syntax and usage: RFC 1738 (Uniform Resource Locators), published in 1994.

Why does this matter for OpenAPI’s history when OpenAPI itself arrived much later? Because an OpenAPI file is built on top of the assumption that “endpoints” are describable in a stable, shareable syntax. Without widely implemented URL conventions, you can’t reliably describe paths, parameters, or server addresses.

In other words, before the Web could standardize API descriptions, it had to standardize the names of things and the rules for reaching them. URL standardization provided that baseline.

Early HTTP Interfaces vs. OpenAPI: What Was Missing (and Why It Matters)

Comparing 1990–1994 HTTP interfaces to a modern OpenAPI-described REST API is a useful way to see what the early Web solved—and what it left unsolved.

What the early Web solved well

• Global addressing: a URL could be shared anywhere and understood by any compliant client.
• A uniform interaction model: request/response with common semantics.
• Format signaling: content types created a shared language for interpreting bytes.

What it did not yet standardize

• Parameter catalogs: there was no universal way to declare, “This endpoint accepts these parameters, with these types and constraints.”
• Response schemas: beyond content types, the structure of payloads was undocumented or described only in prose.
• Error models: consistent, developer-friendly error contracts were not the norm.
• Auth and authorization descriptions: authentication existed in various forms, but describing it in a portable contract format came much later.

This “missing middle” is exactly the problem space OpenAPI eventually targets: a standardized, machine-readable description of the interface surface area that humans can read and tools can act on.

The Real Ancestor of OpenAPI in 1990–1994: Documentation as a Social Contract

In the early Web, the most common API description format was not JSON or YAML. It was a web page: a README-like explanation, maybe an example URL, and a note about what you’d get back.

That sounds primitive, but it produced an important cultural expectation: if you publish an interface, you should document it. That expectation—plus the standards-first mindset of the Web—set the stage for later automation: once people repeatedly write the same kinds of documentation, they eventually want a consistent template. Once they want a consistent template, they start wanting tools. And once tools exist, a specification follows.

If you’re building APIs today, it’s worth remembering that standardized API descriptions didn’t appear out of nowhere. They are the result of decades of pressure to make integration cheaper, clearer, and less dependent on oral tradition. For practical API and automation thinking that builds on those lessons, you can explore additional engineering notes at AutomatedHacks.

Why This Era Still Matters to Modern API Design

Even though OpenAPI is a modern specification, its success depends on ideas that were normalized during the Web’s first years:

• Uniform interfaces scale: the Web taught the industry that a small number of shared primitives beats endless custom protocols.
• Metadata enables tooling: headers and content types were early evidence that shared descriptors unlock automation.
• Identifiers are part of the contract: URL stability and syntax are foundational to any standardized API description.

Chapter 36’s takeaway is simple: the early Web didn’t give us OpenAPI, but it made OpenAPI inevitable by proving the value of standardization—first for documents, then for dynamic interfaces, and eventually for machine-readable API contracts.