If you associate “formal web service contracts” with SOAP, you’re not wrong—SOAP and WSDL later became poster children for strict messaging rules, schema-driven payloads, and machine-verifiable interfaces. But here’s the twist: in 1990–1994, SOAP didn’t exist yet, and the Web was still learning what it even meant to expose an “interface.”

And yet, the forces that eventually produced SOAP-style contracts were already present. The early Web introduced globally addressable resources, a simple application protocol (HTTP), and the earliest patterns for sending inputs and receiving outputs. Those patterns were informal and human-facing, but they planted the seeds for the future: predictable message formats, standardized error handling, and contracts that could be agreed upon without a phone call.

This chapter looks at how the Web’s first few years shaped the idea of formal contracts—long before SOAP made the idea explicit.

1990–1994: When “API” Mostly Meant “Document”

In the early 1990s, the Web grew out of a simple goal: link documents across networks. The most influential “payload format” was HTML, and the most important client was the browser. That mattered for API history because an interface designed for humans tends to hide its contract in prose, page layout, and trial-and-error behavior.

In other words, the contract existed—but it was implicit:

• URLs served as both identifiers and calling conventions.
• HTTP methods were few and used conservatively.
• Responses were typically HTML pages intended to be rendered, not parsed.

From a modern web API perspective, this is a world with “endpoints” but not “developer experience.” There were no OpenAPI docs, no SDKs, and no strong expectation that a machine client would need a stable schema. Still, the Web introduced something that older RPC systems struggled with: a universal addressing scheme (URLs/URIs) and a uniform protocol (HTTP) that could be implemented widely.

The First Web Contracts Were Hidden in HTML and URL Conventions

The earliest HTTP interfaces communicated rules through structure rather than formal definition. If a site exposed a search function, the “API contract” might be understood as:

• There is an HTML form.
• It submits to a URL.
• The query parameters have certain names.
• The response is an HTML document containing results.

That is a contract, but not a formal one. The parameter names are discoverable by viewing the HTML source. The required fields are implied by UI labels. The output schema is “whatever the HTML looks like today.” When developers automated against this kind of interface, they were effectively scraping a user interface—fragile by design, but sometimes the only option.

This is the first major historical bridge to SOAP: SOAP-era thinking insisted that humans shouldn’t have to reverse-engineer an interface from a UI or a page; instead, the interface should be declared in a machine-readable way. In 1990–1994, the Web wasn’t ready for that. But it was already demonstrating the pain of not having it.

HTTP’s Early Shape: A Uniform Interface Without a Formal Schema

Even in the Web’s early years, HTTP hinted at something profound for APIs: a single protocol could act as the transport for many different applications. That’s foundational to later web services.

Two details mattered for “contract thinking”:

1. Headers as metadata: HTTP headers provided a standardized way to describe what was being sent (or requested), even when the body format varied.
2. MIME types (content types): The Web leaned on Internet media types (often called MIME types) so a client could know whether it was receiving HTML, plain text, an image, or something else.

Those weren’t full contracts, but they were contract hooks: stable, standardized fields that tools could depend on. Later SOAP systems would lean heavily on the same idea—messages wrapped in a predictable envelope, with explicit typing and rules about interpretation. In the early Web, MIME types were one of the first steps toward “the message describes itself.”

For readers who want an authoritative overview of how the Web’s protocol stack was organized, the W3C’s protocols documentation remains a useful reference: https://www.w3.org/Protocols/.

CGI and the Birth of Server-Side “Endpoints”

A key shift in 1990–1994 was the movement from static documents to dynamic responses. One of the best-known early patterns was CGI (Common Gateway Interface), which let a web server invoke programs to generate responses.

From an API-history standpoint, CGI created something that looks much more like what we now call an endpoint:

• A URL mapped to executable logic.
• Input arrived via query strings or form submissions.
• Output was returned as an HTTP response with headers and a body.

But again, the contract was mostly informal. There was no universal schema language for payloads, and typical outputs were still HTML. Different CGI programs might interpret the same parameter differently, and error responses were inconsistent. This inconsistency is exactly the kind of operational friction that later “formal contract” approaches tried to reduce.

It’s helpful to think of CGI as a historical stepping stone: it normalized the idea that you could “call” a server over HTTP and get computed output back. That is the conceptual runway for later web services, whether SOAP-based or REST-like.

Why SOAP-Style Contracts Were Inevitable (Even If They Arrived Later)

If 1990–1994 felt contract-light, why talk about SOAP at all in this era? Because the early Web surfaced a tension that grew louder over time:

Humans want flexibility; machines want precision.

Browsers thrive in flexible environments. A browser can display a slightly broken page, ignore unknown tags, and still be “good enough.” But a program integrating with another program needs predictable inputs and outputs. As soon as people started building automation on top of web resources—whether through scripts, early integrations, or enterprise experiments—the demand for precision became obvious.

SOAP, along with WSDL and XML Schema later on, addressed that demand by making the interface explicit:

• Operations were enumerated.
• Types were defined.
• Faults (errors) were structured.
• Tools could generate client code from the contract.

In 1990–1994, you don’t see SOAP yet, but you do see the conditions that make it attractive: heterogeneous systems, growing networks, and the realization that “view source” is not a sustainable integration strategy.

Early HTTP Interfaces vs. Formal Contracts: What Changed in the Industry’s Mindset

To understand the leap from early Web interactions to SOAP-era contracts, compare what each world considered “documentation.”

Early Web documentation (implicit)

• HTML forms revealed parameters.
• Examples in text explained usage (“type your query here”).
• Output was meant to be read, not parsed.

SOAP mindset (explicit)

• A contract is a first-class artifact.
• Validation is expected, not optional.
• Clients can be generated from the spec.

Chapter 7’s takeaway is that the early Web popularized the transport and the addressing model that made later web services scalable. Even if the early Web lacked formal contracts, it introduced a shared substrate that could carry them when the ecosystem was ready.

If you’re building modern automation and want to avoid the early-Web trap of “implicit contracts,” it helps to invest in explicit interfaces and testing. For more applied experimentation around automation and interfaces, you can browse related work at Automated Hacks.

Micro-Lessons from 1990–1994 That Still Matter for API Design

1. URL design is part of your contract. Early systems taught everyone that naming and addressing conventions have long lifespans.
2. Metadata matters. HTTP headers and content types were early examples of self-describing messages. Modern APIs still rely on this principle.
3. Human-first interfaces don’t automatically become machine-friendly. If the “API” is an HTML page, automation will be brittle unless you intentionally support programmatic clients.
4. Standard transports accelerate ecosystems. The Web’s big win wasn’t a perfect schema language; it was a universally implementable protocol that opened the door for everything that followed.

FAQ

Did SOAP exist in 1990–1994?

No. SOAP is associated with the later web services era, after the early Web had already spread. This chapter focuses on how 1990–1994 created the conditions that made SOAP-like formal contracts appealing.

What counted as an “API” on the early Web?

Often it was simply an HTTP-accessible resource: a document, a dynamically generated page, or a server-side script endpoint (commonly via CGI). The “contract” was frequently implied by HTML forms, query parameters, and human-readable output.

What is a “formal web service contract” in plain terms?

It’s a machine-readable agreement that defines how to call a service (operations, inputs, outputs, and errors) so clients can integrate reliably without guessing.

What was the most important contract concept introduced by the early Web?

Uniformity: a shared protocol (HTTP) and shared addressing (URLs/URIs). Even without strict schemas, that common foundation enabled later standardized service contracts to spread widely.