When people talk about SOAP and “formal web service contracts,” the story often jumps straight to the enterprise web of the early 2000s: WSDL files, tool-generated client stubs, and XML envelopes moving over HTTP. But SOAP didn’t appear out of nowhere. The conditions that made SOAP feel necessary were already visible between 1995 and 1998—when most “web APIs” didn’t look like APIs yet.

In that era, the web’s integration layer was built from pragmatic parts: HTML forms, CGI programs, early server-side scripting, and browser scripting (especially JavaScript). These tools created interfaces between systems—even if they weren’t called contracts—and they also exposed the core problem that SOAP tried to solve: how do you standardize a reliable, machine-friendly agreement between independently built systems on the open web?

The “contract” before contracts: form fields, query strings, and shared assumptions

From a modern API perspective, an HTML form submission is a request to a remote service endpoint with a parameter payload. In the mid-to-late 1990s, that was a primary integration primitive.

Consider what a typical form-based interaction required:

• A stable endpoint URL (the action attribute).
• A method (GET or POST), which decided how parameters were carried.
• A parameter schema (input field names), usually documented informally—if documented at all.
• An implied response format, almost always HTML intended for a browser, not for another program.

This was an API contract in everything but name. The trouble was that it was easy to break and hard to validate. If a server changed a field name, a client integration failed. If a response page was rearranged, screen scrapers broke. There was no formal way to declare what was allowed, required, or versioned. The “schema” lived in tribal knowledge, in email threads, or in the source code.

CGI and early dynamic web integration: the original web endpoint pattern

The Common Gateway Interface (CGI) became one of the earliest mainstream patterns for turning HTTP requests into dynamic responses. Instead of serving a static file, the server executed a program that received request details (method, headers, parameters) and emitted a response.

CGI endpoints were effectively “services,” but their contract boundaries were messy:

• Inputs arrived as environment variables or encoded form parameters.
• Outputs were usually HTML with minimal machine-friendly structure.
• Error handling was inconsistent—often an HTML page saying something went wrong.
• Authentication patterns were ad hoc and varied by site.

Still, CGI normalized an idea that matters to API history: a URL can represent a callable operation, not just a document. That mental shift is foundational. SOAP later leaned on that same idea (a network-callable operation), but tried to formalize the message format and expectations.

Browser scripting (1995+) raised expectations for “programmable” web interactions

JavaScript’s arrival in 1995—along with an increasingly scriptable browser—changed the feel of the web. Even before modern asynchronous API calls became common, developers used scripting to validate forms, alter page behavior, and create richer client-side flows.

This mattered for web API history because it increased the pressure for predictable request/response patterns. If you’re generating parameters dynamically or guiding a user through multi-step flows, you quickly discover that:

• You need stable parameter names and predictable server behavior.
• You need structured error signals rather than human-oriented pages.
• You need versioning or at least coordination when endpoints change.

In other words, as the browser became more programmable, developers wanted servers to behave more like dependable components. The web was becoming a platform for application integration—not just publishing.

Why “formal contracts” started to feel necessary

By the late 1990s, organizations were increasingly connecting web front ends to databases, internal systems, and partner services. But most integrations were still improvised:

• A partner might “integrate” by submitting a form-like POST to a URL you provided.
• A back office system might be updated by parsing an HTML response.
• Teams might agree on a parameter list in a spreadsheet and hope it stayed current.

This approach works—until it doesn’t. As soon as you have multiple clients, multiple server implementations, and the need for long-term stability, you want a contract that is:

• Machine-readable (so tooling can validate and generate code).
• Transport-friendly (able to ride on HTTP without unusual infrastructure).
• Language-agnostic (so Java, C++, Perl, and others can interoperate).
• Explicit about structure (types, required fields, and nesting).

SOAP is best understood as an attempt to meet those requirements, using the web’s most widely deployed transport (HTTP) and a structured, standardized data format.

1998: XML becomes a standard—and a key ingredient for contract-driven services

A major milestone arrived in 1998: XML 1.0 became a W3C Recommendation. XML offered something that HTML and “plain text parameters” struggled to provide in a standardized way: a structured, extensible format that could represent data cleanly and could be validated against rules.

If you want to see the authoritative specification that made XML a dependable interchange format for developers and vendors, the W3C’s recommendation is the right reference:
Extensible Markup Language (XML) 1.0 (W3C Recommendation).

XML’s standardization matters to SOAP’s origin story because it gave the industry a shared syntax for structured messages. Once you have that, you can begin to define conventions: envelopes, headers, bodies, and typed payloads. Those conventions are exactly what SOAP later emphasized.

Late-1990s experimentation: moving from “web pages” to “messages”

Between 1995 and 1998, many developers were still thinking in pages: “What HTML should I return?” But a parallel mindset was emerging: “What message should I return?”

That shift showed up in small but important ways:

• Non-HTML responses started to become more common for integrations—sometimes simple key/value text, sometimes early XML.
• More deliberate use of HTTP methods began to appear, even if not yet aligned with later REST thinking.
• Early RPC-style patterns gained visibility, with developers modeling remote operations (e.g., “placeOrder,” “getCustomer”) rather than documents.

One concrete example of this moment is the emergence of XML-RPC around the end of the 1990s. Without over-focusing on exact timing beyond what’s widely known, the important takeaway is that developers were actively exploring XML as a payload for remote procedure calls over HTTP—exactly the conceptual neighborhood where SOAP would later live.

How SOAP reframed the web API contract problem (and why the 1995–1998 era made it plausible)

SOAP’s key promise wasn’t “XML everywhere.” Its deeper promise was formalism in a web-shaped world:

• A standardized envelope so intermediaries and endpoints could reliably parse messages.
• A clear separation between payload and metadata (headers vs. body).
• Compatibility with HTTP so it could move through existing infrastructure.
• A path toward service contracts that tools could understand (later associated with WSDL, even though that came after this chapter’s time window).

The reason these ideas resonated is that web developers had already lived through the pain of informal “contracts” in CGI scripts and form posts. They had seen what breaks: renamed parameters, changing HTML layouts, inconsistent error pages, and undocumented edge cases.

In modern terms, the 1995–1998 web was running a massive experiment in integration without a schema registry, without OpenAPI-like descriptions, and without a consistent error model. SOAP was one of the first widely recognized attempts to impose a consistent message contract across that chaos.

A practical lesson from Chapter 77: contracts don’t start as files—they start as habits

It’s tempting to define “formal web service contracts” as a specific artifact: a WSDL document, a generated client library, a strict schema. But the 1995–1998 period shows that contracts begin earlier, as repeated patterns:

• Choosing stable names for inputs and outputs
• Separating human-facing pages from machine-facing responses
• Documenting behavior as soon as more than one client depends on it
• Designing for change through versioning and compatibility

If you’re building or automating API workflows today, it’s useful to remember how quickly integrations become brittle when “the contract” is only implied. For more writing on practical automation and systems thinking around modern interfaces, you can browse Automated Hacks.

FAQ: SOAP, CGI, and formal contracts in early web API history

Was SOAP actually used between 1995 and 1998?

SOAP is generally associated with the late 1990s and early 2000s, and its broader standardization and mainstream adoption happened after the 1995–1998 window. In this chapter, the focus is on the preconditions: CGI/form-based “APIs,” increasing browser programmability, and the emergence of XML as a standard format that made SOAP-like contracts practical.

Why do HTML forms and CGI count as part of web API history?

They established key API ideas: an addressable endpoint (URL), a request method (GET/POST), named parameters, and a server-side handler that performs an operation. Even if the response was “just a webpage,” the integration shape was recognizable—and it created pressure for more explicit, machine-friendly contracts.

What changed in 1998 that mattered for formal web service contracts?

XML 1.0 became a W3C Recommendation in 1998, giving developers and vendors a shared, standardized way to represent structured data. That made it much easier to define message formats and validate them—critical ingredients for contract-driven web services.

What problem was SOAP trying to solve compared to ad hoc CGI endpoints?

CGI endpoints often relied on loosely defined parameters and returned HTML meant for humans. SOAP aimed to standardize structured, machine-readable messages (typically over HTTP) so different systems could interoperate more reliably, with clearer expectations around message parsing and metadata.