When people talk about WSDL and enterprise API discovery, they usually jump straight to the SOAP era—machine-readable contracts, registries, and tool-generated client stubs. But the need for that level of description didn’t appear out of nowhere. It was created by the Web’s earliest years, when HTTP interfaces began to act like APIs long before anyone consistently used the term “web API.”

This chapter covers roughly 1990–1994, a period where the Web took shape: URLs became shared interfaces, HTTP requests became a practical integration mechanism, and organizations started placing real systems behind web servers. WSDL itself would not arrive until later, so this is not a story of WSDL’s release. It’s the story of the problems the early Web created—and the discovery and description patterns that enterprises later tried to formalize with WSDL-style contracts.

1990–1991: HTTP’s earliest “API” was a URL and a GET

In the earliest Web implementations, HTTP was minimal: a client connected to a server and requested a document. The interface was essentially:

• Addressing: a URL that named the resource
• Method: effectively a “GET-like” request
• Response: the bytes of the document

That simplicity matters for API history. Even without formal schemas, a URL was already a kind of contract. If a team published /docs/spec.html or /data/report, other people could bookmark it, link to it, and rely on it. The “interface” lived in a shared understanding of what the URL meant and what the server returned.

In other words, the Web accidentally introduced a major integration primitive: stable identifiers plus standardized retrieval. Later enterprise API discovery tools would try to recreate and industrialize this: find endpoints, understand what they do, and integrate safely.

1992–1993: Early gateways and dynamic output made HTTP look like an integration layer

As the Web spread beyond static documents, developers quickly pushed it into dynamic territory. By the early 1990s, server-side programs could generate responses on demand (commonly discussed under the umbrella of gateway approaches like CGI, which became widely known as the Web matured). This was a turning point for web API history: once a URL could trigger computation, not just retrieval, HTTP became an integration tool.

Enterprises and research institutions could put a thin web layer in front of an internal system: a database query, a status check, a directory lookup, or a report generator. The calling convention was often a URL with parameters embedded in the path or query string. The response might be HTML meant for humans, but the behavior looked like a service call:

• Send a request to a known endpoint
• Provide inputs (often as query parameters)
• Receive structured-ish output (HTML, plain text, or line-oriented formats)

This era also saw the Web become easier to use thanks to graphical browsers (most famously Mosaic in 1993). That increased demand for content and functionality, which in turn increased the number of endpoints people depended on. More endpoints meant a new problem: how do you discover what exists and what it expects?

Discovery before WSDL: links, directories, and “documentation as HTML pages”

From 1990 to 1994, API discovery was mostly human-driven. There wasn’t a standard machine-readable contract language for HTTP interfaces, and there wasn’t an agreed enterprise service registry. Instead, people discovered interfaces through:

• Hyperlinks (the Web’s native discovery mechanism)
• Curated directories and institutional pages listing “useful services”
• Conventions (predictable URL patterns like /cgi-bin/ or /status)
• Plain documentation written as HTML pages that explained parameters and outputs

In today’s vocabulary, those HTML pages were an early form of API documentation portal. If you squint, they played a similar role to what an OpenAPI description or WSDL document would later do: they told you where the endpoint was, what inputs were accepted, and what came back.

The key difference is that those descriptions were not reliably machine-readable. Tools couldn’t automatically generate clients, validate messages, or check compatibility. Enterprises felt this pain as soon as multiple teams needed to integrate and maintain endpoints over time.

1994: Standardization pressure rises (and enterprise needs start to show)

By 1994, the Web’s growth created pressure for more formal standardization. The World Wide Web Consortium (W3C) formed in 1994, and the broader ecosystem increasingly treated HTTP and URLs as foundational infrastructure rather than an experimental document-sharing system. You can read more about the early Web timeline from the W3C’s historical overview: https://www.w3.org/History.html.

This matters for web API history because standardization is what makes APIs scalable across organizations. When more people rely on the same protocol, you get:

• Repeatable integration patterns (clients and servers built by different teams)
• More intermediaries (proxies, caches, gateways) that influence API behavior
• Higher stakes for compatibility (changes can break many consumers)

At the same time, organizations began experimenting with internal “webs” (what would soon be widely called intranets). Even if many enterprise intranets became prominent later, the early-to-mid 1990s is when a lot of technical teams first recognized that a web server could be a unifying interface in heterogeneous environments.

Why this era created the demand for WSDL and enterprise API discovery

WSDL (Web Services Description Language) is associated with a later period in API evolution, but its core value proposition is easier to understand when you look at 1990–1994 constraints.

Early HTTP interfaces had three recurring problems:

1. Ambiguous contracts

   A URL plus a web page wasn’t a reliable contract. Parameters were often informal, error handling was inconsistent, and response formats could change without warning.

2. Human-only discovery

   Developers could find endpoints by browsing or reading documentation, but tooling could not reliably discover services, understand operations, or generate clients.

3. Scaling maintenance inside organizations

   As soon as multiple teams published endpoints, they needed consistent naming, versioning habits, and a way to answer: “What services do we have, who owns them, and what do they accept?”

Those are exactly the pressures that later enterprise API programs tried to solve with service description languages (like WSDL in the SOAP world) and with discovery mechanisms (registries, catalogs, and governance processes). In other words, the early Web didn’t invent WSDL—but it created the environment where something WSDL-like felt inevitable to large organizations.

In modern teams, we see echoes of this same problem. Whether you publish REST endpoints, event streams, or internal platform APIs, you still need an inventory, ownership metadata, and dependable documentation. Many teams now approach this with API catalogs and automation; for more on practical automation and engineering experimentation, you can explore related work at Automated Hacks.

The hidden lesson of 1990–1994: the interface is the ecosystem

One of the most important takeaways from this era is that an “API” is not just an endpoint. It’s the ecosystem around it: naming conventions, documentation habits, and expectations about stability.

From 1990 to 1994, the Web’s discovery mechanism was built into the medium itself—links and shared pages. That was powerful, but it didn’t scale cleanly inside enterprises where:

• Not everything is linkable from a public page
• Security and access control are mandatory
• Teams need machine-readable contracts for automation
• Ownership and lifecycle management matter as much as the interface

Those realities explain why enterprise API discovery eventually became a dedicated discipline and why formal descriptions like WSDL were so attractive when they arrived: they promised a way to make services searchable, integratable, and governable at scale.

Looking ahead

This chapter’s period ends around 1994, when the Web is clearly more than a research project and standardization begins to catch up with adoption. Next chapters in a chronological API history can more directly connect the dots: expanding HTTP capabilities, growing server-side programming models, and the eventual push for formal interface description and enterprise-grade discovery mechanisms.

For now, the key historical point is simple: the earliest HTTP interfaces made integration easy to start and hard to standardize. That mismatch is the root of the later WSDL and enterprise API discovery story.

FAQ

Did WSDL exist between 1990 and 1994?

No. WSDL is associated with a later era of web services. This chapter explains how early HTTP usage created the need for formal service description and discovery, even though WSDL itself came afterward.

Were there “web APIs” in the early 1990s?

Not in the modern sense of JSON REST APIs with published schemas, but there were HTTP-accessible interfaces: URLs that triggered server-side behavior and returned data (often formatted for humans). These patterns are part of web API history because they influenced later API design and documentation practices.

How did developers discover endpoints before modern API catalogs?

Mostly through hyperlinks, curated directory pages, institutional documentation, and shared conventions. Discovery was largely manual and human-driven rather than automated and machine-readable.

What’s the connection between early HTTP and enterprise API discovery?

Early HTTP made it easy for teams to publish endpoints quickly, which increased the number of services inside organizations. That growth created the need to inventory services, document inputs/outputs consistently, and maintain compatibility—core concerns of enterprise API discovery.