1990–1994: When a URL Was the Interface

In the earliest Web, the central promise was straightforward: a client could request a resource using a uniform addressing scheme (the URL), and a server could respond with a representation (often HTML). If you squint, that’s an API: a contract where a request yields a structured response.

But the contract wasn’t primarily “call a function.” It was “retrieve a document,” and then follow links to retrieve more documents. The design was intentionally generic: HTTP methods, status codes, and headers were meant to be reusable across many domains. Even in the early 1990s, this uniformity mattered because it reduced coordination costs. A new service could be created as long as it spoke the same basic protocol as everything else.

One historical detail to keep in mind: the Web’s earliest deployments were practical and experimental. Implementations differed, features evolved, and some behaviors were conventional rather than rigorously standardized. That doesn’t weaken the story; it strengthens it. It shows how quickly developers began using HTTP not just to publish pages, but to build interfaces between software components.

“Client-Driven” Before GraphQL: Query Strings as Proto-Selections

GraphQL popularized a formal way for clients to specify what fields they need. In 1990–1994, there was no GraphQL query document, no typed schema, no resolver pipeline. Yet clients still influenced responses through mechanisms that look familiar in spirit:

• Query strings (e.g., ?q=term&sort=asc) allowed clients to change search terms, filters, and ordering.
• Path parameters (e.g., /users/123) selected a specific entity representation.
• Headers hinted at preferences (like acceptable formats) even when servers were simplistic.
• Forms generated requests based on user input, turning browsers into interactive clients rather than passive readers.

These patterns weren’t “field selection,” but they were “response shaping.” A user (through the client) could request different slices of information by changing parameters. It’s the same underlying motivation as GraphQL: reduce waste, get what you need, and make the client’s needs explicit.

In modern terms, the early Web was already exploring the boundary between resource retrieval and data querying. That boundary is exactly where GraphQL later planted its flag.

CGI and the First Web API “Handlers”

If early HTTP made everything look like a document, the Common Gateway Interface (CGI) made the Web programmable. CGI let a server pass request information (method, query string, headers, and other environment data) to an external program and then send that program’s output back to the client.

From a web API history viewpoint, CGI mattered because it enabled:

• Dynamic responses driven by client input rather than static files.
• Early “endpoint” conventions where a script name stood in for a function.
• Parameter-driven output that acted like a crude query system.

Developers quickly discovered a key tension: CGI was flexible, but it encouraged ad-hoc contracts. One script might expect ?user=123; another might expect ?id=123. Those inconsistencies weren’t just cosmetic—they influenced whether clients could be generic or had to be hard-coded for each service.

That tension is still with us today. GraphQL’s schema and strongly described query surface can be seen as a later answer to the “every CGI script is its own mini-language” problem.

Hypermedia as a Different Kind of Client Control

When people describe GraphQL, they often emphasize client freedom: the client decides which fields to request and how to traverse relationships. Early Web architecture offered a different, quieter form of client control: navigation.

Instead of requesting a nested object graph in one call, a client would:

1. Request a page or index resource.
2. Follow a link to a related resource.
3. Repeat until it had gathered enough context.

This was client-driven data fetching in a literal sense: the client chose the path. The tradeoff was latency and round trips. You didn’t over-fetch as much because each page might be narrow and purpose-built, but you could easily under-fetch and need several sequential requests. GraphQL later addressed this by letting a client describe a traversal and receive a composed response. The early Web addressed it by making traversal the normal mode of use.

So while the early Web didn’t have GraphQL’s expressiveness, it did have a strong idea of discoverability: clients could learn what to do next from representations, not just from out-of-band documentation.

Why the Early Web Needed “Just Enough” Standardization

In 1990–1994, the Web grew rapidly across institutions, operating systems, and networks. Standardization was necessary, but over-standardization could have slowed adoption. The resulting compromise shaped web APIs for decades: a small, stable core (methods, URLs, headers, status codes) with freedom at the edges.

That small core is still the reason a modern API can be consumed by an enormous ecosystem of tools. It’s also why discussions about “the right abstraction” never end. Should clients get:

• A fixed set of endpoints with stable responses (server-driven), or
• A query language where clients specify exactly what they need (client-driven)?

The early Web leaned toward server-driven representations, but it made room for client influence through parameters and navigation. GraphQL later amplified the client side, but it didn’t invent the desire; it formalized it.

If you want a compact overview of the protocol family that supported these early interfaces and evolved alongside them, the W3C’s protocol resources are a helpful reference: https://www.w3.org/Protocols/.

Lessons for Today: Reading GraphQL Back Into 1990–1994 (Carefully)

It’s tempting to tell a neat story: “Early HTTP led to REST, and REST led to GraphQL.” Real history is messier. Still, it’s useful to use GraphQL as a modern lens to interpret early web API instincts, as long as we don’t pretend the tooling or terminology existed then.

Three practical lessons stand out:

1. Clients will always find ways to ask for less (or more). If the server doesn’t offer response shaping, clients resort to hacks: extra round trips, custom endpoints, or duplicated data.
2. Loose interfaces scale adoption, but tight contracts scale collaboration. Early CGI-like patterns made it easy to publish something quickly, but harder to build long-lived shared clients. Modern schemas (including GraphQL) trade some freedom for clarity.
3. Uniform transport is a superpower. HTTP’s generality made it possible for unrelated systems to interoperate. Even when payloads were simple, the shared transport unlocked ecosystems.

If you’re building modern API integrations and you want more practical guidance on automation and interface reliability, you might also explore resources at Automated Hacks.

FAQ

Did GraphQL exist between 1990 and 1994?

No. GraphQL came much later. This chapter uses GraphQL as a modern reference point to explain older ideas about letting clients influence responses.

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

Often, it was an HTTP-accessible interface exposed through URLs, query parameters, and server-side scripts (commonly via CGI). It wasn’t always called an API, but it served the same purpose: enabling a client to request data or actions from a server.

How did early clients shape the data they received without field selection?

Mostly through query strings (filtering, searching, paging), choosing different resource URLs, and navigating via links to fetch related information in separate requests.

What’s the main historical connection to client-driven data fetching?

The early Web normalized the idea that a client can express intent in a request—by selecting a resource, providing parameters, and choosing what to follow next—rather than receiving a single fixed dataset every time.

What can modern API designers learn from 1990–1994?

Keep the transport simple and consistent, make client intent explicit, and treat discoverability and documentation as part of the interface—not afterthoughts.