When developers talk about “web APIs,” they often jump straight to REST, JSON, and modern cloud platforms. But the story starts earlier—before the word “API” was common in everyday web development. In the 1995–1998 era, the web’s dynamic layer was being stitched together with browser scripting, CGI programs, and HTML forms. Those building blocks created a practical problem: once a browser could submit data and a server could generate a response, how should structured data move between systems reliably?

This is where XML as a data exchange format begins to matter in the chronology of web APIs. XML didn’t instantly become “the API format” the moment it was standardized. Instead, it emerged as a strong candidate precisely because the mid-to-late 1990s web was messy: diverse servers, inconsistent clients, and a patchwork of scripting approaches all needed a common language for structured information.

1995: Browser scripting and the first taste of client-driven “requests”

Around 1995, browser scripting (especially early JavaScript) started changing expectations. While much of the web was still static HTML, scripts made pages feel interactive—validating forms, toggling UI elements, and reacting to user input without a full page redesign.

Yet nearly all serious “data operations” still required leaving the page and going back to the server. That round trip—user action → HTTP request → server processing → HTML response—formed an early shape of what later became API-driven development. Not because developers exposed neat endpoints, but because they were forced to think in terms of inputs and outputs.

In 1995, there wasn’t a mainstream pattern for browsers to fetch structured data in the background. The interaction model was mostly:

• HTML forms submitting name/value pairs
• CGI scripts reading those values and generating HTML
• Cookies (newly introduced in the mid-1990s) helping maintain sessions

Even without “API endpoints,” this created a critical idea: the web could be a universal transport layer (HTTP), and applications could communicate by sending structured inputs and interpreting structured outputs.

1996: CGI, server glue, and the limits of “HTML as the response format”

CGI was a workhorse for early dynamic sites. It offered a simple contract: the server launches a program, passes request information (often through environment variables and standard input), and the program prints an HTTP response.

This was effectively an API—just not a cleanly separated one. It encouraged a style where the “data” and the “presentation” arrived entangled as HTML. That was fine for humans reading pages, but it was awkward for computers trying to integrate systems.

As businesses began connecting catalogs, directories, and internal databases to the public web, they ran into a repeating integration pain:

• One system knew products by SKU, another by internal ID.
• One system expected dates formatted one way, another expected something else.
• One team emitted HTML tables; another team tried to parse them.

Parsing HTML for data extraction was possible but brittle. A single markup change could break downstream consumers. So, even before XML was widely deployed in APIs, the need for a presentation-independent data format was becoming obvious.

1997: Forms, query strings, and the accidental “endpoint” pattern

By 1997, more developers were building interactive experiences with forms—search boxes, shopping carts, sign-ups, and early account portals. The web’s integration vocabulary increasingly included:

• GET with query strings for searches and lookups
• POST bodies for submissions
• Session identifiers via cookies or URL rewriting

These conventions looked a lot like what we now call “endpoints,” even if they were implemented as CGI programs or server-side scripts returning full HTML pages. Developers learned—sometimes the hard way—that stable parameter names and predictable outputs mattered. Once a partner depended on ?q=term&category=books, you couldn’t casually rename it.

In other words, interface stability started to become a business requirement. That pressure is a direct ancestor of API versioning, schema discipline, and backward compatibility.

1998: XML 1.0 arrives at exactly the right moment

The year 1998 is a major marker because W3C published the XML 1.0 Recommendation. XML was designed as a simplified, web-friendly subset of SGML—structured enough for data, but meant to be easier to implement and exchange than SGML in everyday systems. The specification is still publicly available from the W3C: Extensible Markup Language (XML) 1.0.

This matters in web API history because XML offered something the 1995–1997 web lacked: a broadly standardized way to represent structured data that could travel over HTTP without being confused with presentation markup.

XML’s advantages in that late-1990s context were practical:

• Self-describing structure via nested elements and attributes
• Unicode support that helped globalization efforts
• Strict rules (well-formedness) that made parsing more reliable than “best-effort” HTML parsing
• Extensibility—teams could define their own tags without waiting on browser vendors

It’s important not to overstate the timeline: in 1998, many dynamic sites still returned HTML, and many integrations still used ad-hoc flat files or custom formats. But XML’s standardization made a promise that was hard to ignore: you could define a contract for data exchange independent of page layout.

How XML connected to the “early API” mindset—even before modern AJAX

If you picture a modern web API, you likely imagine a client requesting /api/orders/123 and receiving structured data. In 1995–1998, the client was usually a browser submitting a form and receiving HTML. But organizations were already performing machine-to-machine exchanges behind the scenes and experimenting with programmatic consumers.

XML helped shift thinking from “generate a web page” to “produce a document that represents the data.” That distinction laid the conceptual groundwork for:

• Separating data from presentation (a precursor to service-oriented design)
• Defining schemas and shared contracts (even when formal tooling matured later)
• Interoperability across platforms in a web ecosystem split across operating systems, server stacks, and browser quirks

And it fit neatly with the web’s transport model. HTTP didn’t care whether you sent HTML or XML. That meant the “API surface” could remain familiar—URLs, headers, request bodies—while the payload became more structured and machine-friendly.

Why this chapter matters in the longer web API timeline

Chapter 76 (1995–1998) is a transitional slice of history: the web moved from static documents to interactive applications, but the tooling wasn’t yet standardized around clean service boundaries. Developers relied on CGI, server scripting, and forms as the integration layer, and they learned that HTML wasn’t a dependable data contract.

XML’s arrival in 1998 didn’t instantly solve integration, but it gave developers a credible “common envelope” for structured information. Later, whole ecosystems would grow around XML-based service definitions and messaging patterns. But the seed was planted here: the late-1990s web needed a structured, portable, and standard data format, and XML was designed to meet that need.

If you’re tracing how automation and integration patterns evolved from “submit a form” to “call an endpoint,” it helps to see XML as one of the earliest widely standardized answers to a question the web had already been asking for years: how do we exchange data reliably between systems built by different teams?

For more practical perspectives on how automation thinking continues to shape modern integrations, you can also browse https://automatedhacks.com/.

FAQ: XML and early web API history (1995–1998)

Was XML used for web APIs immediately after it was standardized?

Not immediately. In the late 1990s, many web interactions still returned HTML. XML’s 1998 standardization made it easier to justify structured payloads over HTTP, but broad “API-first” patterns took time to become mainstream.

Why weren’t HTML responses enough for early integrations?

HTML was aimed at presentation for humans. Computers can parse HTML, but small layout changes can break data extraction. Teams needed a stable, structured format that treated data as data, not as a visual table.

How did CGI and forms influence API design?

They normalized the idea of passing inputs to a URL and getting a computed response back. Even though responses were often HTML, the consistent use of parameters, request methods, and predictable outputs pushed developers toward interface stability—one of the core concerns of API design.

What did XML add that earlier custom formats didn’t?

XML provided a widely published standard with strict parsing rules, extensibility, and broad platform support. Custom formats could work, but they were harder to share across organizations without ambiguity or special-purpose parsers.