When developers talk about Facebook Platform APIs, the conversation usually begins in the mid-2000s, when large-scale social networks started opening their data and identity systems to third-party applications. But the “social graph API” mindset—treating relationships, identity, and interactions as something software can query and act on—didn’t appear out of nowhere.

This chapter looks backward on purpose. In 1995–1998, the web didn’t have today’s JSON conventions, OAuth flows, or “Graph API” endpoints. What it did have were the building blocks: HTML forms, CGI scripts, early browser scripting (especially JavaScript), and the first widespread practices for tracking user state. Those tools formed the earliest, messy-but-important version of what we now recognize as web API integration. Later, platforms like Facebook would refine these ideas into standardized developer products—permissions, tokens, callbacks, and structured data about people and connections.

1995–1998: The web discovers “inputs,” “state,” and “integration”

In the mid-to-late 1990s, most websites were still page-centric. But as soon as developers began using forms and server scripts to create personalized experiences—logins, comments, simple profiles—the web started drifting toward a more API-like architecture. Even if nobody called it an “API” yet, the fundamental loop was familiar:

• The browser sends structured input (form fields).
• The server executes code (CGI).
• The server returns a structured response (HTML page, sometimes with machine-readable fragments).
• The system tries to remember who you are (cookies and sessions).

Facebook’s social graph later depended on these exact primitives: input and response contracts, identity persistence, and predictable rules for cross-site or third-party integration.

HTML forms as early “request schemas”

HTML forms were one of the first widely adopted mechanisms that forced developers to think in terms of structured requests. A form field is essentially a named parameter. A form submission is essentially a method call. The action URL is an endpoint.

From a modern API historian’s view, forms created the earliest popular “schemas” on the web:

• Parameter names (e.g., username, email, message) mattered because back-end code relied on them.
• Encoding rules mattered because the server needed to parse the data correctly.
• Validation started to appear as developers realized users could submit unexpected values.

If you’ve ever implemented a modern login endpoint, you can recognize the same thinking: define required fields, accept data in a known format, validate it, then return a response that represents success or failure.

For a standards reference point on how forms and documents were specified as the web matured, see the W3C’s HTML recommendation: https://www.w3.org/TR/html401/.

CGI: endpoint design before REST had a name

Common Gateway Interface (CGI) scripts were an early bridge between the web server and application logic. While CGI wasn’t a “web API framework” in the modern sense, it created many enduring integration conventions:

• Distinct URLs for actions (e.g., /cgi-bin/register, /cgi-bin/postcomment).
• Server-side parsing of query strings and form bodies.
• Response construction via headers and HTML output.

Most importantly, CGI pushed developers to think about the boundary between the browser and the server. That boundary is exactly where web APIs live today. Later, Facebook would formalize that boundary with versioned endpoints, structured data formats, and developer documentation. But the mental model—“the client calls an endpoint with parameters, the server returns a result”—was already common by the late 1990s.

Browser scripting (1995+) makes the client an active participant

JavaScript arrived in the mid-1990s and quickly changed how developers approached dynamic behavior. Instead of submitting a form and waiting for a full page reload, scripts could:

• Pre-validate inputs before sending them to the server.
• Change page content based on user actions.
• Coordinate multiple UI states (menus, tabs, simple widgets).

This matters for Facebook Platform history because later social API integrations often depended on “active client” patterns. A social login button, an embedded share widget, or a permissions prompt requires the browser to orchestrate UI and network steps in a controlled sequence. In 1995–1998, developers were already learning the essential lesson: the browser is not just a document viewer; it’s a runtime.

Cookies and sessions: identity becomes portable (and sticky)

The idea of a social graph depends on identity: you can’t model relationships between people if you can’t reliably identify the current user. In the late 1990s, a huge step forward was the widespread practice of using cookies plus server-side sessions to maintain user state across requests.

Even if early “accounts” were simplistic—sometimes little more than a username and a stored preference—they introduced key API-adjacent concepts:

• Session identifiers passed automatically with each request (a precursor to token-based auth headers).
• Authorization checks (“is this user allowed to post/edit/view?”) happening on the server.
• Personalization based on stored state (what you’d later call user-scoped data).

When Facebook later built its platform for third-party apps, it didn’t merely expose data. It exposed identity and user-scoped permissions at scale. The practical roots of that system—state, identity continuity, and server-side authorization—were already part of everyday dynamic website construction by the late 1990s.

Early dynamic community features: proto-graph thinking

Between 1995 and 1998, many sites experimented with features that look surprisingly “social” in hindsight:

• Guestbooks and comment forms created public interaction trails.
• User directories and simple profiles appeared on community sites.
• Web rings and link exchanges formed manual networks of affiliation.
• Forums created relationship-like structures between users and topics.

These systems didn’t represent relationships as an explicit, queryable graph, and they usually weren’t exposed to third-party developers via dedicated endpoints. But they established the value proposition that made a social graph inevitable: relationships and interactions are data, and data becomes more valuable when software can reuse it across contexts.

From ad-hoc “integration” to platform APIs: what Facebook later standardized

It’s tempting to view Facebook’s developer platform as a clean break from early web development, but it’s more accurate to see it as a standardization wave. Here’s how the 1995–1998 toolkit maps to later platform API design patterns:

1) Forms and CGI → endpoints and payload contracts

Forms taught the web to send structured key/value data to a server endpoint. Facebook’s later APIs made the payloads richer and more consistent (eventually shifting toward structured responses and predictable error handling), but the foundational contract—client sends parameters, server returns a result—was already mature.

2) Cookies/sessions → tokens and scoped authorization

Sessions demonstrated that identity can persist across requests. Facebook later scaled this idea into a permissioned system where the same user identity could authorize different apps with different scopes. Even without naming modern standards, the direction was clear: identity should be portable, but controlled.

3) Browser scripting → embedded widgets and interactive flows

Early JavaScript enabled interactivity and validation. Later, platform integrations relied on the same browser runtime to coordinate multi-step workflows (login prompts, consent, redirection, and callback handling).

4) Community pages → explicit relationship models

Guestbooks and forums generated social data but stored it in page-shaped silos. The social graph concept reorganized it: instead of “pages with comments,” you could have “users connected to users, users connected to content, and content connected to actions”—a structure that could be queried and reused by software.

Why this matters for web API history (and for developers now)

Studying 1995–1998 isn’t nostalgia; it’s pattern recognition. The modern web API ecosystem—including platform APIs like Facebook’s—grew out of recurring needs:

• Consistency: endpoints and parameters must be predictable.
• Security: identity and permissions must be enforced server-side.
• Interoperability: third parties want to build on top of existing user bases and data.
• User experience: the browser must coordinate dynamic workflows smoothly.

In other words, the “platform era” didn’t replace early dynamic web techniques; it industrialized them. If you’re building integrations today—webhooks, OAuth redirects, embedded widgets—it can be useful to remember that the core challenges have been with us since the first CGI scripts started accepting form posts.

If you’re interested in practical automation and modern experiments that still echo these older integration patterns, you might also explore resources at https://automatedhacks.com/.