When developers say “web APIs,” most people picture JSON over HTTP: a browser or server calling an endpoint, getting a structured payload back, and moving on. That mental model is accurate for modern systems, but it can trick us into imagining that JSON was there from the beginning.

It wasn’t. In the 1990–1994 era—when the Web was still becoming the Web—HTTP was primarily a document delivery mechanism. Yet, even in those early years, the core ingredients of web APIs were already forming: a request/response protocol, standardized headers, media (content) types, and a growing expectation that software could talk to software using simple, text-friendly conventions.

This chapter focuses on that early period: the birth of the Web and the earliest HTTP interfaces, and how they established the habits that later made lightweight formats like JSON feel natural.

JSON as a Destination, Not a Starting Point

JSON became popular much later, so it’s important to frame it correctly in a 1990–1994 history: JSON is the destination of several early design pressures, not the origin.

Those pressures were already obvious in the early Web:

• Text beats binary when you want interoperability across different machines and programming languages.
• Loose coupling is easier when messages are self-describing (headers + body) and can evolve.
• Small payloads matter on slow networks and limited servers, so “lightweight” exchange becomes a feature.
• Name/value data is the simplest common denominator for forms, queries, and script interfaces.

By the time JSON arrived, HTTP had already trained developers to expect a clean separation between metadata (headers) and payload (body), and to treat the payload as a flexible document that could be parsed by whatever tool they had available.

1990–1994: A Web Built for Documents, Yet Ready for Interfaces

In the earliest Web implementations, HTTP interactions were straightforward: a client requests a resource, and the server returns it. The primary resource type people cared about was HTML. But even then, HTTP had a broader structure: it could carry different types of content, and it provided a disciplined envelope for exchange.

That envelope matters to API history because it becomes the stable transport layer that APIs build on top of. In modern terms, we’d call it a uniform interface: the same verbs and message framing can support documents, images, data feeds, or machine-readable payloads.

Key building blocks that emerged early

• URIs/URLs as identifiers: an addressable “thing” becomes the unit of interaction. APIs later adopt this as “resource endpoints.”
• Headers as metadata: even if early HTTP was minimal, the broader direction was clear—metadata belongs in a structured header area.
• Media types (MIME): standard labels for payload formats made it possible to add new data representations without changing the transport protocol.

That last bullet—media types—was crucial. The Web borrowed and aligned with MIME conventions, giving developers a common way to say, “this is plain text,” “this is HTML,” or later, “this is JSON.” For the early 1990s, the story is less about JSON specifically and more about how the Web standardized the idea that payloads need a declared type. If you want to go deep on the era’s foundation for content typing, the MIME specification is a good reference: RFC 1341 (MIME).

Lightweight Data Exchange Before “API Payloads” Were a Thing

So how did early HTTP interfaces exchange data if not with JSON?

The answer is: mostly through conventions that look surprisingly familiar today—just less formal and less standardized. In practice, early Web data exchange leaned heavily on:

1) Query strings and URL-encoded name/value pairs

By the early 1990s, it was common to embed parameters in a URL as a query string. This wasn’t “structured data” in a modern sense, but it was lightweight, human-readable, and easy to parse in almost any language.

Conceptually:

• The client sends: /search?q=cat&limit=10
• The server responds: an HTML page (often), or a plain text result list

From an API history perspective, query strings were an early proof that the Web could support parameterized operations, not just static document retrieval. Even though the response might be HTML, the interaction pattern (request with arguments → response) is API-shaped.

2) HTML forms as data submission interfaces

HTML forms were a major turning point: they gave the browser a standardized way to collect user input and send it to the server. The server-side processing was not standardized at the HTTP layer, but forms established a predictable input format—again, typically name/value pairs.

This mattered because it normalized the idea that the Web wasn’t only for reading; it was also for sending data back to a program that would respond with computed output.

3) Plain text and ad hoc structured formats

In the early 1990s, developers often exchanged data as text/plain and invented simple conventions: line-based records, delimiter-separated values, or repeated key: value lines inspired by mail/news formats.

These were “lightweight” in the most literal sense: small, simple, and designed for quick parsing. They weren’t always interoperable across organizations, but they were interoperable across tools—because any system can handle text.

CGI: The Early Web’s First Widely Used API Adapter

If there’s a single early-1990s technology that deserves to be called an API milestone, it’s CGI (the Common Gateway Interface). CGI emerged in the early 1990s as web servers and developers needed a consistent way to run external programs in response to HTTP requests.

CGI wasn’t an “API format” like JSON. It was an interface between the web server and application code. But it quietly established patterns that later became standard API practices:

• Inputs are parameters: request method, query string, and headers become inputs your program can read.
• Outputs are typed: the program prints a Content-Type and a body.
• Statelessness is normal: each request starts fresh (or at least appears that way), which pushed developers toward self-contained messages.

In other words, CGI turned “web server returns files” into “web server calls code.” That is essentially the leap from publishing documents to offering services.

And because CGI outputs were often text-based, it encouraged exactly the kind of lightweight interchange that would later become synonymous with JSON APIs.

Why MIME and Content Types Were the Secret Sauce

Modern JSON APIs rely on a simple, powerful contract: the client and server agree that the payload is JSON, usually declared as application/json. In 1990–1994, that specific media type wasn’t the point—but the contract mechanism was already there in spirit.

Once you have a system where:

• messages have headers,
• the body can be any format,
• and the format can be declared,

you’ve created a platform where new representations can be introduced without redesigning the whole network protocol.

That’s one reason JSON later fit so cleanly into HTTP: it didn’t have to fight the transport. It just had to become a widely accepted representation.

A Mini Timeline (1990–1994) Through an API Lens

Exact “firsts” in this era can be hard to pin down because the Web evolved through implementations, drafts, and community practice rather than a single formal release. Still, the arc is clear:

• Early 1990s: HTTP is used mainly to retrieve documents; URLs and basic request/response patterns become familiar.
• Early-to-mid 1990s: HTML forms and parameterized URLs normalize sending input to servers.
• Around 1993–1994: CGI becomes a practical bridge for dynamic responses; servers increasingly act as gateways to programs and data sources.
• By 1994: developers widely understand “a URL can trigger a program” and “the response can be more than a static file,” setting the stage for more formal API approaches later.

If you build APIs today, it’s worth noticing how much of your day-to-day work is still rooted in these early ideas: endpoints, parameters, content types, and stateless requests.

How These Early Patterns Shaped the Future JSON API Mindset

Even without JSON, the early Web pushed developers toward a few durable design instincts:

Keep it simple enough to debug with basic tools

Early HTTP traffic could be inspected with minimal tooling. Lightweight text outputs could be read directly. That “debuggability” became a hidden requirement for later web APIs, and JSON benefited because it’s readable and easy to log.

Use a common envelope, vary the payload

HTTP’s message framing allowed experimentation with payload formats. That’s why modern APIs can standardize on HTTP while evolving representations over time.

Prefer conventions that survive language and platform differences

Name/value pairs, line-based text, and declared content types were early strategies for interoperability. JSON eventually became the most convenient common language for the same goal.

For teams building modern automation around APIs, it’s useful to remember that “lightweight exchange” is more than a performance choice—it’s a cultural inheritance from the early Web. If you’re exploring practical automation patterns that sit on top of HTTP APIs today, you may also like the engineering notes and experiments at Automated Hacks.

FAQ: Early Web Data Exchange and the Road to JSON

Did JSON exist between 1990 and 1994?

No. JSON became a widely recognized format later. In 1990–1994, the Web relied more on HTML, plain text, and simple name/value encodings for lightweight data exchange.

What was the closest thing to an API in the early Web?

CGI-based endpoints and parameterized URLs were among the closest equivalents. They allowed clients (often browsers, sometimes scripts) to send inputs and receive computed responses over HTTP.

Why do MIME types matter for API history?

MIME introduced a standard way to label content formats. That concept—declaring the payload type—later made it straightforward for HTTP-based APIs to adopt formats like JSON without changing the underlying protocol.

Were early HTTP responses machine-readable?

Sometimes. Many responses were HTML meant for humans, but plain text and other simple formats were common in practice, especially when developers wanted lightweight interchange or were building gateway scripts.