The early 1990s Web was already an interface

In the early Web, “interface” mostly meant humans clicking links. Yet the essential mechanism was an interface between a client and a server: a structured request that gets a structured response. Even when HTTP was simpler than today’s versions, it still introduced several lasting ideas that matter for API history:

• Everything addressable gets an identifier (eventually standardized as URLs/URIs). If a thing has a URL, it can be retrieved, referenced, cached, and linked.
• Uniform interaction: a small set of operations (like requesting a resource) is applied consistently across many different resources.
• Statelessness as a default: early HTTP interactions didn’t assume long-lived sessions. Each request stood alone.
• Hypermedia: links embedded in responses taught clients what could happen next.

Those bullets could describe a modern API design handbook. But in 1990–1994, they were more like survival tactics for a networked system that had to work with limited servers, primitive browsers, and an Internet culture still forming around open standards.

From documents to “resources”: the mindset shift that enabled the social graph

Facebook’s social graph is, at its core, a model of entities (people, pages, groups) and relationships (friends, followers, members), plus a stream of content attached to those entities. That seems far removed from the early Web’s “document” focus. But the shift that made the social graph possible was already happening by the early 1990s: the Web taught developers to treat information as resources with stable names.

A resource didn’t have to be a static document forever. It could be a computed response, a directory listing, or a page produced by a program. Once the Web normalized the expectation that “a URL represents a thing you can fetch,” it became natural—years later—to map users, posts, and relationships to endpoints.

Put differently: Facebook didn’t invent the idea that a “person” could have a canonical address on the network. The Web’s early emphasis on global identifiers made that feel obvious. The social graph simply took the idea further, expanding “things with URLs” from pages to people and relationships.

1993–1994: forms, query strings, and the first wave of Web-as-application

By around 1993 and into 1994, the Web began to feel less like a read-only library and more like an interactive system. The pivotal enablers weren’t just “better browsers,” but specific interface patterns:

• HTML forms created a standard way for a client to collect user input and send it to a server.
• Query parameters made it practical to encode input directly in URLs, turning navigation into a primitive function call.
• Server-side gateways (notably CGI) allowed servers to generate responses dynamically based on request data.

This is where web API history begins to look like recognizable “endpoints.” A form submission to a CGI script could accept parameters (like a search term), do computation (like query an index), and return a generated page. It wasn’t JSON. It wasn’t an SDK. But it already had the essential anatomy of an API call: inputs, processing, and outputs over HTTP.

That matters for Facebook Platform APIs because the platform era was built on exactly these patterns, refined: parameters, permissions, server-side logic, and structured responses. The difference is that Facebook later standardized data formats and authentication mechanisms for third-party developers. The early Web standardized the transport and the expectation of request/response automation—even when the response was meant for a human reader.

Hypermedia: links as the original “API discovery” mechanism

Modern developer platforms often rely on documentation portals, SDKs, and API explorers. The early Web’s discovery tool was simpler: links. A page didn’t just contain information; it contained affordances—a set of possible next actions represented by clickable references.

In web API design terms, that’s a powerful concept: clients can be guided by the responses they receive. Facebook’s later platform ecosystem leaned heavily on out-of-band documentation (and, at times, breaking changes that required careful migration). But the deeper web heritage is hypermedia: the response contains navigable structure.

Even if Facebook’s social graph endpoints were not purely link-driven in the early implementations, the idea of representing relationships as something you can traverse—moving from a user to their connections to their content—echoes the early Web’s link traversal model. The social graph is a specialized, structured descendant of the Web graph.

Why 1990–1994 matters to “Facebook Platform APIs” even though Facebook came later

To write accurate API history, you can’t pretend Facebook existed in 1994. What you can do is track the lineage of concepts that later converged in Facebook’s Platform APIs. In 1990–1994, the Web established several norms that became prerequisites for any large-scale developer platform:

1) A universal, low-friction protocol for integration

HTTP’s simplicity (especially early on) made it easy to implement clients and servers. That low barrier is what allowed “integration” to become commonplace. Facebook Platform APIs later benefited from the same dynamic: an API call is “just HTTP,” so every language and environment can participate.

2) Addressability as product surface

Once you can give a stable identifier to a thing, you can build products around it: caching, bookmarking, sharing, indexing, analytics. Facebook later operationalized this for people and objects in a social system. The early Web operationalized it for documents.

3) A mental model of graphs

The early Web popularized the idea that value comes from connectivity: one page leads to another, and meaning accumulates through references. Facebook’s social graph intensified that principle by making relationships first-class and measurable. But the “graph-shaped” intuition was already planted by the Web’s link structure.

4) Stateless calls that can scale

Large platforms need interfaces that don’t require fragile, chatty conversational state. Early HTTP interactions, by default, encouraged independent requests. When Facebook later served massive volumes of API traffic, the stateless request pattern was one of the reasons HTTP-based APIs could scale operationally.

A note on standards: early HTTP’s legacy in today’s API conventions

If you want a modern, developer-friendly overview of how HTTP works—the same core protocol that underpins most web APIs today—this reference is reliable and clear: MDN Web Docs: An overview of HTTP. While the early 1990–1994 implementations were simpler than what’s described there, the continuity is the point: the Web’s earliest interface patterns became the default transport for API ecosystems later on.

When you look at Facebook Platform APIs through that lens, the “social graph” becomes less like a sudden invention and more like a concentrated expression of the Web’s original promise: globally addressable resources connected through navigable relationships.

Bringing it back to developers: the early Web as the first developer platform

In the early 1990s, developers didn’t have app stores, OAuth consent screens, or polished API dashboards. But they did have something arguably more important: an open set of conventions that anyone could implement. That openness allowed experimentation—some of it messy, some of it brilliant.

Facebook Platform APIs later formalized the idea of “third-party developers building on top of a network.” The early Web did something similar in a decentralized way: anyone could stand up a server, publish resources, and connect them. That’s why web API history has to begin here. Before platforms sold APIs, the Web gave away the core interoperability model.

If you’re building modern integrations and want to see how these long-running patterns show up in practical automation and tooling, you can explore additional engineering notes at https://automatedhacks.com/.

FAQ

Did web APIs exist in 1990–1994?

Not in the productized sense we use today (documented REST endpoints returning JSON), but the core mechanics of web APIs did: HTTP request/response, resource identifiers (URLs), parameter passing via query strings and forms, and dynamic server responses via early gateway approaches such as CGI.

What does the early Web have to do with Facebook’s social graph?

The early Web normalized global identifiers and link traversal. Facebook’s social graph extends those ideas by treating people and relationships as addressable entities that can be traversed and queried through HTTP-based interfaces.

Why focus on 1990–1994 in a history of Facebook Platform APIs?

Because Facebook’s later APIs depended on conventions established when the Web was born: simple interoperability over HTTP, addressable resources, and graph-like navigation via links. Understanding that foundation clarifies why HTTP became the default substrate for large developer platforms.

What’s the biggest lesson from this era for modern API design?

Keep the interface uniform and the identifiers stable. The early Web scaled because it made interaction predictable and resources easy to reference. Those principles still matter when designing platform APIs today.