When people talk about “public web APIs,” they usually picture JSON responses, API keys, and developer portals.
But the roots of public APIs on the Web go back to the Web’s earliest years—roughly 1990 through 1994—when
a “public interface” often meant nothing more than a URL that accepted parameters and returned a document.
This era matters because it introduced the core contract that still defines web APIs today: a client sends an HTTP request to a stable address, and the server responds with a representation.

In this chapter of our chronological history of web APIs, we’ll zoom in on the birth of the Web and the first
widely copied pattern for early HTTP interfaces: the URL-as-function. We’ll also look at how early Web builders
accidentally invented proto-mashups—combinations of multiple sources into one page—long before “mashup” became a popular term.

1990–1994: The Web’s first “API design” decision was the URL

The earliest Web was built around documents, not services. Still, a document address (a URL) quickly became
the universal handle for “something you can ask a server for.” That “something” might be a static HTML page,
but it could just as easily be the output of a program.

The key idea wasn’t fancy serialization; it was standardization of addressing. By 1994, URL syntax was described in an IETF RFC,
helping cement a shared mental model across implementations and server software.
If you want a primary source from the period, see RFC 1738 (Uniform Resource Locators).
Even though developers weren’t calling these endpoints “APIs” in the modern sense, the rulebook for interoperable addressing was already forming.

Once a URL could carry a query string, the leap from “document address” to “callable interface” was natural.
A server could interpret parameters and generate output dynamically. In practice, that meant early endpoints that looked like:
/search?query=… or /lookup?name=…, returning HTML that humans read but machines could also parse.

Early HTTP methods: small verbs, big consequences

Today, REST discussions obsess over HTTP verbs. In the early 1990s, the point was simpler:
HTTP provided a minimal set of request methods that encouraged a uniform interface. GET was the workhorse, and
HEAD offered a lightweight way to check metadata without transferring the full body.

This mattered for API history because uniform methods separated the transport from the application.
If a client could connect, send a request, and receive a response with headers and a body, it could interact with anything
from a static page to a computed “report.” That basic shape of interaction is still what we mean by a web API call.

It’s tempting to project today’s expectations backward and assume early Web builders were designing “API endpoints.”
More often, they were trying to solve practical problems: publishing updated lists, exposing a directory search,
or providing a gateway to data that already existed elsewhere.
But those pragmatic solutions created reusable patterns: stable URLs, parameterized requests, and predictable output.

Gateways and CGI: the moment Web pages became callable interfaces

A major milestone in the early 1990s was the rise of server-side gateway programs.
Different servers had different mechanisms, but the general approach was consistent: the server received an HTTP request,
invoked a program, and sent the program’s output back as the HTTP response.
Later, this family of techniques became widely known under the umbrella term “CGI” (Common Gateway Interface),
though the ecosystem evolved over time and different implementations appeared as the Web grew.

In API terms, this was huge. It meant a URL could trigger computation. A request could:

• Query a database or directory
• Proxy a request to another network service
• Format results into HTML for humans (and incidentally, into patterns parsable by scripts)
• Act as a thin “adapter” between the Web and older protocols

If that sounds like an API gateway, it’s because the basic concept was already there—just without the modern vocabulary.
These early scripts were often brittle and tightly coupled to server configuration, but the architectural motif—HTTP in, computed response out—was durable.

Public web APIs before “public API programs” existed

During 1990–1994, organizations weren’t typically advertising official public API programs.
Yet the Web’s default openness meant many endpoints were effectively public:
if you knew the URL, you could request it.

What counted as an “API” in practice?
Often it was any resource with predictable structure that third parties could incorporate into their own pages.
Early Web builders learned quickly that if you kept URLs stable and outputs consistent, others could rely on them.
That reliance is the beginning of API consumption.

The responses weren’t JSON. They were mostly HTML (and sometimes plain text).
But in terms of software history, that’s an implementation detail.
The more important part is that a public interface was emerging around:
standardized addressing, standardized transfer, and repeatable results.

Proto-mashups: combining sources before the word “mashup” existed

The mashup idea—combining multiple services into one new experience—is usually associated with a later era.
But the behavior started early.
In 1990–1994, a “mashup” might not be a slick single-page app. It might be a simple HTML page that aggregated information and links from multiple origins.

Here are a few historically plausible proto-mashup patterns from the early Web period:

• Link aggregation with implied contracts: curated pages that linked into multiple external directories, archives, and institutional servers.
  The “contract” was stability: if those links kept working, the aggregator stayed valuable.
• Server-side composition: a gateway script could fetch or query more than one source, then render a single result page.
  Even if the upstream sources were non-HTTP services, the gateway translated them into an HTTP response.
• Embedded assets as integration: images or other media loaded from other servers were a lightweight form of composition.
  The page became a client of multiple origins, and the browser stitched the pieces together.

These approaches sound basic, but they established an enduring lesson for API history:
once information is reachable via stable network interfaces, people will combine it.
“Mashups” are less a product category than an instinct.

Why this era set the direction for modern API design

Between 1990 and 1994, the Web’s growth pushed a few principles into the mainstream that directly shaped public APIs later:

1. Uniform interface wins: a small, consistent set of operations (requests and responses) scales better than custom protocols.
2. Identifiers are everything: stable URLs (and later, broader URI practice) let communities form around shared resources.
3. Human-first output can become machine input: early API consumers often “screen-scraped” HTML.
   That pain later motivated cleaner formats, but it also demonstrated demand.
4. Composition is inevitable: once resources are accessible, third parties will assemble new experiences—proto-mashups first, formal integrations later.

If you’re building automation today, it’s worth remembering that “API thinking” isn’t only about response formats.
It’s about dependable interfaces and predictable behavior over time.
Teams that care about those fundamentals tend to ship integrations that last.
For more practical experimentation around automation and interfaces, you can explore related projects at
Automated Hacks.

Chapter 13 takeaway: the earliest public APIs were just Web resources that stayed predictable

In the 1990–1994 window, the Web was still young, and the term “public web API” hadn’t solidified.
Yet the ecosystem already had the ingredients that make APIs work: addressing (URLs), transport (HTTP), and server-side programs that generated responses.
From those pieces came the first reliable, shareable interfaces—and the first hints of mashups as people combined resources into something new.

In later chapters, we’ll see how these patterns hardened into explicit developer-facing APIs, richer content types, and eventually the machine-friendly formats and authentication strategies that define modern API platforms.
But the core idea remains surprisingly unchanged: a Web API is a promise you can call.