The Web in 1995: Dynamic Pages Without “APIs”

By 1995, the web was no longer just static documents. Sites were beginning to feel “application-like” thanks to three forces working together:

• HTML forms that collected user input and sent it to a server endpoint.
• CGI (Common Gateway Interface) programs that turned HTTP requests into dynamic responses.
• Browser scripting (especially early JavaScript) that changed what users could do before submitting a request.

Developers may have described this as “dynamic web,” “interactive sites,” or “database-backed pages.” Yet under the hood, they were already building a kind of API surface—one defined by URLs, query strings, headers, and method semantics (even if used imperfectly).

Forms as the Proto-API Contract: GET and POST in Everyday Use

HTML forms were arguably the most widespread “client SDK” of the era. A form’s action attribute named an endpoint. The method attribute selected GET or POST. Input names became parameters. And the browser automatically encoded those parameters in the query string or request body.

This mattered historically because it normalized several API concepts that remain central today:

• Addressability: A URL identified where to send a request and often implicitly “what” the request was about.
• Uniform interface (in practice): Even when developers overused POST, the web platform nudged them toward a small set of standard operations.
• Representations: The server sent back HTML as the representation of some underlying state (a search result, a shopping cart, a guestbook entry list).

A typical 1996-era search page can be read as a primitive resource-oriented API:

• GET /search?q=stargazer returned a representation (HTML) of the “search results” resource.
• POST /cart/add changed server-side state (add an item) and returned the updated cart page.

Developers weren’t describing these as resources yet, but the structure was already there: stable endpoints, consistent naming, and repeated interactions over HTTP.

CGI: The First Mass-Scale “Endpoint Handler”

CGI’s importance to web API history is easy to overlook because it feels primitive by today’s standards. But CGI established a crucial mental model: the server receives an HTTP request, parses inputs, performs business logic, and emits an HTTP response with headers and a body.

CGI programs commonly depended on environment variables (method, path, content type) and standard input (request body). The output began with headers, followed by content. That lifecycle maps surprisingly well onto the request/response processing pipelines used in modern frameworks.

More importantly, CGI encouraged a URL-to-behavior mapping culture. Endpoints like /cgi-bin/guestbook.pl or /cgi-bin/order.cgi were not “APIs” in name, but they were the practical interface between a web client and server-side capabilities. Over time, developers began to notice that endpoints based on nouns (things) were easier to evolve than endpoints based on verbs (actions)—a key stepping stone toward resource-oriented thinking.

Browser Scripting (1995–1998): Interactivity Without True In-Page API Calls

JavaScript emerged in the mid-1990s and quickly became part of how web pages behaved. Yet in 1995–1998, most browser scripting did not call APIs in the modern sense (no standard, ubiquitous asynchronous request object yet). Instead, scripting enhanced API-like interactions through:

• Form validation before submitting (reducing server load and round trips).
• Dynamic construction of query strings (effectively generating GET requests programmatically).
• Navigation-driven “integration” where scripts changed window.location to hit an endpoint.
• Hidden frames and image requests used as lightweight tracking and signaling mechanisms (a workaround for the lack of robust in-page request tools).

These patterns sound clunky now, but they mattered historically because they reinforced the idea that URLs are an interface. Developers saw that if a URL was predictable and parameterized, it could be used by more than just a human clicking links. That lesson is a direct ancestor of today’s API-first mindset.

State, Sessions, and the Push Toward Clearer Boundaries

Another problem from this era shaped REST’s later emphasis on statelessness: session management. As shopping carts, logins, and personalization spread, developers needed ways to keep continuity between requests. Approaches included:

• Cookies to carry identifiers across requests.
• URL rewriting (embedding session IDs in links) when cookies weren’t reliable.
• Server-side session stores that accumulated user state.

These techniques worked, but they highlighted a tension: the more state the server kept, the harder it became to scale, cache, or debug interactions. Even before REST was formalized, many teams learned through experience that minimizing conversational coupling between client and server made systems easier to operate.

1997 and HTTP/1.1: Caching, Semantics, and the Web as an Application Platform

If you want a single standards milestone that tightened the relationship between “web pages” and “web APIs” in this era, look at HTTP/1.1 work in the late 1990s. HTTP/1.1 clarified and expanded behavior around caching, request/response semantics, and intermediaries—elements that are foundational to REST-style systems.

Developers often experienced this not as “API architecture” but as practical concerns:

• Cache correctness: When should a proxy or browser reuse a response?
• Conditional requests: How can a client avoid re-downloading unchanged content?
• Method meaning: When is it safe to retry a request?

These questions are central to REST because REST leans on the web’s existing semantics rather than reinventing them. For an authoritative snapshot from that time, see the IETF RFC that documented HTTP/1.1 in the late 1990s: RFC 2068 (HTTP/1.1).

Resource-Oriented APIs Before They Had a Name

So what exactly was “resource-oriented” in 1995–1998?

It showed up whenever developers chose stable, meaningful URLs that represented things users cared about, even if the response was HTML rather than JSON. Consider common patterns of the time:

• Catalog browsing: GET /products?category=books returned a representation of a filtered collection.
• Item pages: GET /product?id=123 (or later, cleaner paths) returned one item’s representation.
• Guestbook entries: POST /guestbook created a new entry and then redirected to the collection view.

Even when the URLs were messy (query parameters everywhere) or the server endpoints were implementation-flavored (.cgi, .pl), the guiding idea was surprisingly modern: a URL can identify a thing, and HTTP can operate on it.

From today’s perspective, you can see the web’s “uniform interface” peeking through the cracks: GET for retrieval, POST for submission, redirects after state change, and cacheable responses for content. The vocabulary wasn’t settled, but the ingredients were on the table.

Why This Era Matters to REST Architectural Style History

REST architectural style is often associated with later API design conversations. But the foundational constraints it champions—stateless interactions, cacheability, layered systems, a uniform interface—were already being stress-tested by real sites in 1995–1998.

This era taught developers, sometimes painfully, that:

• Good URL design is product design. When URLs were stable and meaningful, linking and integration became easier.
• HTTP semantics are leverage. When systems aligned with method meanings and caching rules, performance and reliability improved.
• Overloading POST hides intent. Teams began to see that when everything is “submit,” interfaces become harder to understand and evolve.
• Representations can change while resources remain. A resource could be “the cart” even if its HTML layout changed weekly.

Those lessons are what later made “resource-oriented APIs” feel natural: they were already the web’s default mode of operation, just waiting to be named, refined, and applied intentionally.

If you’re tracing how these early patterns connect to modern automation and API thinking, you may also enjoy related explorations at Automated Hacks, where web-facing interfaces are often discussed from a practical, builder’s perspective.

FAQ: 1995–1998 and the Road to REST

Was REST used in 1995–1998?

Not as a commonly used term or formal framework in day-to-day development. However, many behaviors that REST later emphasized—like using URLs to identify things and relying on HTTP’s standard operations—were already widespread because they were built into the web platform.

Were there “web APIs” before JSON and AJAX?

Yes, though they often returned HTML and were consumed by browsers through navigation and form submission rather than in-page asynchronous calls. CGI endpoints and form handlers functioned as early APIs in practice.

Why is HTTP/1.1 important for API history?

HTTP/1.1 clarified caching, request semantics, and intermediary behavior—core features that enable scalable, reliable, resource-oriented systems. Those semantics later became central to REST-style API design.

What’s the biggest design takeaway from this era?

Interfaces last longer than implementations. When developers treated URLs and HTTP behaviors as a contract, their systems were easier to extend, integrate, and maintain—exactly the kind of thinking that resource-oriented APIs formalized later.