Before “Web API” Meant an Endpoint

When people say “public web API” now, they typically mean a documented interface over HTTP—often REST-like—returning structured data (JSON, XML) with clear authentication and versioning. In the 1995–1998 era, that definition was still forming.

Yet the core idea behind public web APIs already existed: one system exposing capabilities that another system could reuse over the network without sharing a codebase. The web’s universal substrate—URLs, HTTP requests, and HTML responses—made it possible to integrate across organizational boundaries even when the response wasn’t designed for machines.

This period matters because it normalized two behaviors that would later define API ecosystems:

• Remote invocation: triggering a server-side action by sending a request with parameters.
• Composition: combining outputs from multiple remote systems into a single user experience (the ancestor of “mashups”).

HTML Forms as the Earliest “Public Interface”

In the mid-1990s, HTML forms were the everyday developer’s gateway to dynamic behavior. A form submission was essentially a structured request: a set of named fields encoded into a query string (GET) or request body (POST). Even when nobody called it an “API,” it functioned like one: a stable contract of parameter names and expected values.

Think about what forms enabled:

• Search pages that accepted a q parameter and returned results.
• Catalog filters, date selectors, and location lookups.
• Login workflows and session initiation.

Once a site exposed a predictable search form, other developers could treat it as a semi-public interface. They could automate requests, bookmark parameterized URLs, or build internal tools that “spoke” the same parameter language. It wasn’t always officially supported, but the pattern trained developers to think in request/response contracts—one of the foundations of later public web APIs.

For a standards anchor point on how forms and scripting were expected to behave by the late 1990s, the W3C’s HTML specification is a useful reference: HTML 4.01 Specification.

CGI: The Workhorse “API Layer” Before Frameworks

If forms were the interface, CGI (Common Gateway Interface) was often the engine behind it. CGI scripts—written in Perl, C, shell, and other languages—translated HTTP requests into program execution. The web server passed request details via environment variables and standard input; the script printed an HTTP response header and body.

From a web API history perspective, CGI did two major things between 1995 and 1998:

1. It made HTTP a developer-facing integration protocol. You didn’t need special middleware. If you could craft a URL or POST body, you could drive a remote behavior.
2. It encouraged parameter conventions. Query names and formats started to become semi-stable because changing them broke inbound links, bookmarks, and integrations.

CGI also introduced early “API design problems” we still recognize today:

• Output formats optimized for humans. HTML pages were easy to render but hard to parse reliably.
• No formal versioning. A small layout change could break a downstream integration—an early example of the “scraping breaks” problem.
• Security and input validation pitfalls. CGI popularized the need for careful sanitization, since user input directly influenced server-side execution paths.

Even with these constraints, CGI gave developers a mental model that would later map cleanly onto public web APIs: “Send request with parameters; receive response with data.”

Browser Scripting: The Client Becomes an Integration Surface

Another big shift in 1995–1998 was the rise of browser scripting. JavaScript (and, historically, alternatives like JScript and VBScript in certain environments) made web pages reactive. Client-side code could validate forms, modify the DOM, and coordinate navigation flows without reloading entire pages for every minor interaction.

While modern developers associate web APIs with JavaScript calling fetch(), that model wasn’t mainstream yet. Still, browser scripting pushed the web toward API-like integration in several ways:

• Parameter assembly: scripts could construct URLs based on user choices, effectively generating dynamic “API calls” via navigation.
• State handling: cookies and hidden form fields carried state across requests, making multi-step workflows possible.
• UI composition: pages could blend data from different sources by redirecting, embedding, or reusing snippets.

In hindsight, this was a precursor to mashups: the browser became a runtime where multiple systems could influence one experience. The integration mechanisms were clunky by today’s standards, but they taught developers that the client could orchestrate interactions across servers.

Early Dynamic Web Integration: The Mashup Mindset Before the Term

The word “mashup” would become common later, but the instinct to combine services emerged early. Between 1995 and 1998, “mashups” often looked like:

• Link-driven composition: one site generating deep links into another site’s search results or item pages using known query parameters.
• Embedded content: including remote assets such as images, counters, or syndicated fragments (sometimes via frames/iframes) to enrich a page.
• Backend-to-backend glue: a server-side script fetching remote pages or data files and transforming them into a new HTML page.

These patterns mattered because they established expectations that are central to public web APIs:

• Predictability: integrations only worked when URLs and parameters stayed stable.
• Documentation by example: developers learned interfaces from observed traffic, sample URLs, and trial-and-error.
• Reusability: if you could reuse someone else’s data or workflow, you could ship features faster.

In other words, mashups didn’t appear out of nowhere in the 2000s. The habit of recombining web-accessible functionality was already forming in the late 1990s; it just lacked the clean tooling and official blessing that later API programs would provide.

Publicness Without Official APIs: “Accidental Interfaces”

A key theme of web API history in this era is that many “public APIs” were not labeled as such. They were public because the web is public by default. If a feature was reachable via a URL and accepted parameters, it was, functionally, an interface.

These accidental interfaces created both opportunity and tension:

• Opportunity: third parties could innovate quickly by reusing existing capabilities.
• Tension: site owners could change behavior at any time, breaking integrations and prompting early debates about what a stable interface owed its consumers.

This is also where you can see the early shape of later API governance questions: Who controls the contract? What guarantees exist? How do you evolve an interface without breaking dependents?

Why 1995–1998 Set the Stage for Modern Web APIs

Even without today’s terminology, the late 1990s created a practical bridge between static pages and programmable platforms. Forms and CGI normalized parameterized requests. Browser scripting normalized client-side orchestration. Together, they pushed the web toward the idea that:

• Websites are not just documents; they are services.
• URLs are not just addresses; they can be commands with inputs.
• Pages can be composed from multiple sources, paving the way for mashups.

If you’re building modern integrations, it’s worth revisiting these roots because many “new” issues—stability, versioning, automation, and the line between intended APIs and scraping—are echoes of this era. For more practical experimentation and automation-minded perspectives that connect historical lessons to modern workflows, you can also explore https://automatedhacks.com/.

FAQ

Were there public web APIs between 1995 and 1998?

Some interfaces were publicly reachable and reusable over HTTP, but many were not presented as “APIs” with formal documentation. They were often form-driven endpoints or CGI-backed URLs that functioned as informal, sometimes accidental, public interfaces.

How did mashups work before modern JavaScript HTTP requests?

Mashup-like integration often relied on link-driven composition (constructing URLs with parameters), embedding remote assets, or server-side scripts that fetched and transformed remote content into a new page.

Why are HTML forms important in web API history?

Forms standardized the idea of named inputs submitted as structured data over HTTP. That request/response contract—parameters in, results out—trained developers to think in ways that later mapped directly to formal APIs.

What was the biggest limitation of these early “API-like” integrations?

Responses were usually optimized for humans (HTML), not machines, and there was little to no versioning guarantee. Small layout or parameter changes could break downstream integrations.