When developers talk about “real-time” on the web today, the conversation almost immediately lands on the WebSocket API: a browser-friendly way to keep a network connection open and move messages in both directions with low overhead. But the question that WebSockets answered—“How do we update a page instantly, without reloading?”—was already lurking in the Web’s earliest years.

In this chapter’s slice of web API history (roughly 1990 through 1994), the Web was being born, HTTP was evolving from a tiny document protocol into a more general interface, and the first server-side “APIs” appeared as pragmatic hacks rather than formal contracts. The punchline is a little ironic: the Web started on top of TCP (which can support persistent, bidirectional sessions), yet early HTTP interfaces encouraged the opposite behavior—short-lived, one-way transactions.

Understanding that early mismatch is the best way to understand why WebSockets would eventually matter so much.

1990–1991: HTTP’s earliest interface wasn’t an “API,” but it behaved like one

In the earliest Web implementations (around 1990 and into 1991), HTTP was minimal. The core interaction pattern was straightforward: a client connects, asks for a resource, receives it, and the connection ends. In modern terms, that’s a single request/response exchange—stateless and simple.

Even without a formal “web API” label, the Web already had the essence of an API interface:

• A standard method of requesting something (a URL-based resource request).
• A predictable response (a document stream, initially with very limited metadata).
• An interoperability goal: different clients and servers could speak the same basic protocol.

But what it did not have was any real path to “live updates.” The protocol’s cultural default was: fetch a thing, show it, move on. That mentality shaped early web API history because it encouraged developers to think in discrete transactions rather than ongoing conversations.

1992–1993: The Web expands, and the limitations of request/response become obvious

As the Web gained momentum—especially with influential early browsers like NCSA Mosaic appearing by 1993—the types of applications people wanted to build started to stretch beyond static documents. The Web began to look like an application platform, even though its plumbing still assumed document retrieval.

This is where “real-time” needs begin to show up as negative space: chat-like experiences, dashboards, multiplayer interactions, and monitoring tools all want the server to push information without waiting for a user to click refresh.

In 1993, there wasn’t a standardized browser scripting environment like we expect now. JavaScript would not arrive until later, which matters because modern real-time patterns rely heavily on script-driven network calls and event-driven UIs. Without that, early web “interactivity” leaned on:

• Form submissions (user-initiated requests).
• Full page reloads (expensive, visually disruptive updates).
• Server-generated HTML (the server decides everything, each time).

So if you wanted live updates, the early Web forced a blunt tool: keep asking.

1993–1994: CGI scripts become early “web APIs” (without the name)

One of the most important developments for web API history in this era is the rise of server-side gateway mechanisms—most famously CGI (Common Gateway Interface). CGI wasn’t “a web API standard” in the modern REST/JSON sense, but it created a repeatable way for clients (via browsers) to trigger server programs through HTTP requests.

Here’s why CGI matters to the eventual story of WebSockets and real-time communication:

• It normalized HTTP as an application interface. You weren’t only retrieving documents; you were invoking programs.
• It encouraged parameter passing. Query strings and form fields became a proto-API input mechanism.
• It exposed the friction of statelessness. Each request started fresh; “session” had to be simulated.

In other words: by the early-to-mid 1990s, developers were already using HTTP endpoints like callable interfaces. They just weren’t calling them “APIs” yet, and they weren’t built for continuous streaming updates.

Why “real-time” was hard in early HTTP: the interface discouraged ongoing conversations

It’s tempting to say, “Why not just keep the TCP connection open?” After all, TCP is a stream. But early HTTP usage patterns—and early browser/server implementations—didn’t treat HTTP as a durable session. They treated it as a quick exchange.

Several practical constraints shaped the interface:

• Short connections were simpler. Managing many long-lived client connections is harder for servers, especially with the hardware constraints of the time.
• Proxies and intermediaries were emerging. As the Web grew, middleboxes would become part of the network reality, and long-lived, nonstandard flows were brittle.
• UI expectations were document-based. Browsers were optimized for rendering a page, not for continuously receiving event streams and updating components.

So early “real-time” attempts usually meant some form of polling: the client checks repeatedly for changes. Polling is not elegant, but it’s compatible with the core HTTP interface pattern of that era: ask, receive, disconnect.

The WebSocket idea, seen from 1990–1994: a missing primitive

WebSockets, as a standardized browser API, belong to a much later phase of web API evolution. Still, the need for WebSockets is visible in this 1990–1994 window as a missing primitive: the early Web lacked a clean, standardized way for a server and a browser to keep a lightweight, bidirectional channel open for messages.

If we describe WebSockets in the most historically relevant way (without skipping ahead into standards timelines), it’s essentially three promises that early HTTP interfaces did not make:

1. Keep the connection open without pretending every message is a new document.
2. Allow server-to-client messages that aren’t just responses to a user-triggered request.
3. Reduce repeated overhead (headers, reconnect cost, redundant requests) that polling inevitably creates.

From the perspective of web API history, those promises are not “nice-to-haves.” They are a new category of interface—message-oriented rather than document-oriented.

Early patterns that foreshadowed real-time APIs (without claiming modern standards)

Within 1990–1994 itself, you won’t find a single, universally adopted “real-time web API” mechanism the way we’d talk about today. But you can see the ingredients that later approaches would systematize:

1) Client pull (manual refresh as the first “real-time” UX)

The earliest real-time experience on the Web was simply refreshing a page. It’s primitive, but it established a behavioral norm: the client initiates updates.

2) Automated polling (the idea, even if tooling lagged)

As soon as developers could reasonably automate repeated requests (via early browser features, helper applications, or later scripting), polling became the obvious next step. Polling is historically important because it uses plain HTTP as an API transport: repetitive GET requests to check for new data.

3) Long-lived responses (an intuition that the response could be a stream)

Even if the early Web’s mainstream usage favored quick responses, the underlying technology stack made streaming responses conceptually possible. The idea of holding a connection open to deliver incremental updates was in the air, even if it wasn’t yet a stable, standardized browser pattern during this early window.

How this era shaped web API history: the Web chose universality over interactivity

The most durable contribution of 1990–1994 to web API history is not a specific “real-time protocol.” It’s the set of tradeoffs that defined the Web’s early success:

• HTTP was easy to implement. That lowered the barrier for servers and clients, accelerating adoption.
• Resources were addressable via URLs. This became the backbone of API endpoint design later on.
• Stateless interactions scaled conceptually. You didn’t need a shared session model to retrieve a document.

Those choices made the Web explode in popularity, but they also deferred real-time interactivity. The WebSocket API can be understood as a later correction: keeping the Web’s reach while reintroducing the idea of an ongoing conversation.

If you’re building modern automation or integration-heavy systems, it’s useful to remember that history. A lot of today’s “event-driven” tooling is compensating for a Web that was designed to be read first and interacted with later. For more modern explorations of automation patterns that build on web APIs, see Automated Hacks.

Connecting the dots to WebSockets (for further reading)

While this chapter focuses on 1990–1994, you don’t have to stop there if you want to understand the modern interface. The WebSocket API is documented in current developer references, including MDN’s WebSocket API documentation, which explains how browsers expose persistent connections for real-time messaging.

The key historical takeaway is simple: WebSockets didn’t appear because developers suddenly wanted “real-time.” They appeared because the Web’s earliest HTTP interfaces made real-time awkward, and the ecosystem spent years working around that limitation.

FAQ: Early Web and the road to the WebSocket API

Did WebSockets exist between 1990 and 1994?

No. The WebSocket API and its standardization came much later. This chapter explains how the early Web’s request/response model created a long-term demand for a real-time, bidirectional interface.

What counted as a “web API” in the early 1990s?

In practice, anything you could invoke over HTTP in a repeatable way behaved like an API. CGI scripts are a common example: an HTTP request triggered a server-side program that produced output, often dynamically.

How did early sites approximate “real-time” updates?

Mostly by reloading pages or repeatedly requesting updated resources (polling). Those approaches fit HTTP’s early transaction style but were inefficient and didn’t support true server-initiated messaging.

Why didn’t early HTTP just keep a connection open for updates?

Long-lived connections increase server complexity and didn’t align with early browser/server assumptions or the document-focused user experience. The Web prioritized simple, interoperable document retrieval first, then evolved toward richer application behaviors later.