1995: Forms + CGI — the first widely used “API contract”

By 1995, the web’s most reliable client-to-server data mechanism was the HTML form. It’s easy to underestimate how “API-like” forms were. A form defined:

• Input names (field identifiers) that acted like parameter keys
• Encoding rules that turned user data into a standardized wire format
• A destination (the server URL) that acted like an endpoint
• A method (GET or POST) that implied semantics about where the data lived

In practice, forms trained an entire generation of developers and users to accept a simple deal: send name/value pairs to a URL; get back a response page. That’s a recognizable ancestor of today’s request/response web API pattern—even if the response was HTML meant for humans instead of data meant for programs.

The Common Gateway Interface (CGI) filled in the other half of the contract. A CGI script could read form inputs from environment variables or stdin, query a database, and then emit an HTTP response. Many early “integrations” were essentially this: a web page as a thin UI wrapper around server-side logic exposed through a stable URL.

If you want a period-appropriate snapshot of how forms and their submission model were described, the HTML 2.0 specification (mid-1990s era) is a useful reference: https://www.rfc-editor.org/rfc/rfc1866.

Why “lightweight data exchange” mattered before JSON

Even without JSON, the mid-1990s web had pressures that pushed toward lighter data exchange:

• Slow connections made smaller payloads feel dramatically faster.
• Server costs encouraged simpler request parsing and cheaper responses.
• Browser limitations made repeated full-page reloads clunky for interactive experiences.
• Integration demand grew as businesses wanted websites to talk to inventory, search, customer records, or email systems.

In other words, web developers were already trying to move “just enough information” over HTTP—often as compact name/value pairs—long before JSON became the default. The web didn’t start as an API platform, but it began acting like one as soon as forms met server scripts.

1995–1996: Browser scripting turns the page into a programmable client

The arrival of browser scripting (notably JavaScript in Netscape-era browsers, with other vendors following) changed the client side from a static document viewer into something closer to a small runtime environment. This mattered to API history because it introduced a new idea: the browser could prepare and interpret structured data rather than merely collect inputs.

Even when a request still went through a form submit, JavaScript could:

• Validate fields before sending (reducing server round-trips)
• Construct or modify query strings on the fly
• Copy values into hidden inputs (a primitive way to attach extra parameters)
• Persist small bits of state in cookies and resend them later

This is a subtle but pivotal shift in web API evolution: the “client” became capable of following rules, handling edge cases, and shaping requests. That capability would later make true programmatic data exchange—like JSON-driven APIs—feel natural.

1996–1997: Cookies, session IDs, and the rise of stateful endpoints

CGI scripts were initially simple: one request in, one response out, with little memory of what came before. But real applications needed sessions: logins, shopping carts, and multi-step workflows. Cookies became a practical mechanism for linking requests together.

From an API-history perspective, cookies did something important: they created an implicit parameter channel that traveled alongside explicit form fields. The browser automatically attached cookie headers to subsequent requests, letting server endpoints behave more like stateful services than isolated scripts.

This period also normalized patterns we now associate with APIs:

• Session identifiers (often opaque tokens) used to look up server-side state
• Authorization by possession (if you had the token, you were “in”)
• Consistent endpoint behavior across multiple calls

While not “JSON and REST,” it was undeniably a move toward “a client repeatedly calling a server interface.”

1997: Standardizing the language that would later inspire JSON

In 1997, ECMAScript was standardized, putting a vendor-neutral foundation under the JavaScript language family. This matters to JSON’s story because JSON is essentially a disciplined subset of JavaScript’s object literal notation (with a few important constraints, like mandatory double quotes for keys in strict JSON).

But in 1997–1998, that future wasn’t a given. Developers were using JavaScript to manipulate pages, pass data through forms, and occasionally embed structured information inside scripts—often by inventing small conventions. Many of those conventions resembled what JSON would later formalize: arrays, objects, strings, numbers, booleans, and null-like sentinels.

So even though JSON itself wasn’t defined yet, the idea that data could be expressed in a JavaScript-friendly structure was already circulating in practice. The browser had become a natural consumer of structured data because it already ran a language designed to handle objects and arrays.

1997–1998: Early dynamic web integration without XMLHttpRequest

When people think of “calling an API from the browser,” they often think of AJAX. But the XMLHttpRequest object is typically associated with a bit later momentum. In 1995–1998, developers still found ways to do partial updates and background-like calls using the tools available:

• Frames/iframes to load a server response without navigating away from the main page
• Image beacons (assigning a URL to an image) to trigger a GET request that logged or updated something server-side
• Script tag loading in limited ways, where the server response could be executable JavaScript (a conceptual ancestor to later JSONP-style patterns)

These weren’t standardized “API calling” patterns, and they were often brittle. Yet they reinforced an important mental model: a web page could trigger a request for a small unit of work and incorporate the result into the user experience. That mental model is the same one that made JSON-based APIs explode in popularity later—once the tooling and standards were ready.

So where does JSON fit, if it didn’t exist yet?

JSON’s eventual success can look inevitable in hindsight, but it’s clearer when you see what the 1995–1998 web was missing.

During this era, developers had plenty of ways to send data to servers (mostly name/value pairs via query strings or POST bodies), but there was no universally comfortable way to return structured data for programmatic use in the browser. HTML responses were easy to display but awkward to parse reliably. Custom delimited formats existed, but every delimiter choice became a mini-standard that broke when the content got complicated.

JSON solved that later by offering:

• A compact text format suited to the web’s bandwidth realities
• Native affinity with JavaScript’s syntax and data types
• A predictable structure that programs could parse consistently

In that sense, the 1995–1998 period is best understood as the “pressure chamber” that created demand for JSON. The web was already doing lightweight exchange; it just lacked a clean, standard payload format designed for software on both ends.

Practical takeaway: the pre-JSON era still shapes API thinking

If you build or document web APIs today, it’s useful to remember that many conventions come from this earlier period:

• Parameter naming discipline began with form field names that had to stay stable.
• GET vs POST expectations were socialized through form submission behavior.
• Session management grew from cookies and server-side session stores.
• Integration by URL (a stable endpoint) predates formal API portals and SDKs.

Modern API work often adds layers—authentication standards, typed schemas, versioning policies—but the underlying shape is familiar: a client sends small, structured inputs; the server returns something useful.

If you’re exploring automation and interface-driven integration from a modern perspective, you may also want to browse https://automatedhacks.com/ for related practical experiments and write-ups.

FAQ: JSON, Lightweight Data, and Early Web APIs (1995–1998)

Did JSON exist between 1995 and 1998?

No. JSON as a named, formalized data format came later. In 1995–1998, the web relied heavily on URL-encoded name/value pairs and HTML responses, while JavaScript object notation existed as a language feature without being positioned as a standard data interchange format.

What was the closest thing to an API in 1995?

For most developers, it was an HTML form posting to a CGI endpoint. The “API” was essentially: agreed-upon field names and a server script that interpreted them and returned a result page.

How did browsers handle “structured data” before JSON?

Often poorly. Developers embedded data in HTML, used simple delimiter-based text formats, or relied on server-generated JavaScript in limited scenarios. These approaches worked but were fragile, especially as data got more complex.

Why is this era important to web API history?

Because it established the request/response habits—parameters, endpoints, sessions, client scripting—that later made JSON-based APIs feel like a natural evolution rather than a brand-new invention.