When developers talk about “service registries,” UDDI (Universal Description, Discovery, and Integration) often comes to mind. But UDDI itself belongs to a later chapter of web services history. If you zoom in on 1995–1998, you’ll find something more foundational: a messy, inventive period where the modern ideas behind API discovery and service catalogs began forming—well before the industry had a standard label for them.

This was the era when CGI scripts powered early dynamic sites, HTML forms quietly became a machine-friendly interface, and browser scripting (especially early JavaScript) started turning the browser into a programmable client. Teams didn’t call these “web APIs” in the way we do today, but they were already solving the same problems: How do I call a service? What parameters does it accept? How do I find the endpoint? How do I keep track of what exists?

1995–1998: Before “Web APIs,” the Web Still Needed Interfaces

In the mid-1990s, the web’s center of gravity was shifting from static documents to interactive applications. The shift wasn’t powered by a single invention; it was a stack of pragmatic building blocks:

• CGI (Common Gateway Interface): A standardized way for a web server to execute a program (often in Perl or C) and return generated HTML. It became the backbone of early “API-like” server logic.
• HTML forms: A user interface element that also acted like a transport mechanism. Submitting a form created a structured request with named fields—basically parameters.
• Query strings and POST bodies: Not new concepts, but they became a de facto contract between browser and server: keys, values, encoding rules, and expected responses.
• Early JavaScript: Introduced in the mid-1990s and adopted quickly enough to change expectations. Client-side logic could validate inputs, transform parameters, and “glue” multiple web interactions together.

The result was an early kind of dynamic integration: services that weren’t “APIs” in name but behaved like them in practice. A weather page generated by CGI might accept a ZIP code and return a forecast. A corporate intranet search tool might accept a query parameter and return a results page. Developers learned to treat these endpoints as callable interfaces, even if the response was meant for humans.

HTML Forms as the “Proto-API Contract”

Today, an API contract might be OpenAPI, JSON Schema, or a typed client SDK. In 1995–1998, the contract was often implicit:

• The form field names were the parameter names.
• The form action URL was the endpoint.
• The HTTP method (GET vs. POST) signaled how to send data.
• The HTML response was the output format, even when developers wanted to parse it programmatically.

This mattered for the history of web APIs because it trained an entire generation of developers to think in terms of inputs, outputs, endpoints, and documentation. If you wanted to integrate two systems, you frequently ended up reverse-engineering or informally documenting the “form API.”

In other words: the web already had interfaces. It just didn’t have a clean, standardized discovery layer.

The Discovery Problem: Where Early “Registries” Came From

If UDDI is remembered as a structured way to publish and discover services, then the 1995–1998 era is when teams first felt the pain that would motivate such a system. The question wasn’t academic. It was operational:

• Which CGI endpoints exist on this server?
• What parameters do they accept?
• Who owns them?
• Are they stable enough to integrate into another workflow?

Without a formal registry, companies invented their own “service directories” using whatever tools were available:

1. Intranet index pages: A hand-maintained HTML page listing internal tools and scripts, often organized like a table of contents.
2. Shared folders and README files: A network share with scripts and notes—primitive, but searchable.
3. Email threads as documentation: People asked “what’s the URL for X?” and the answer became tribal knowledge.
4. Corporate directories and naming services: Not “web registries” exactly, but directory concepts (like organizational lookup and hierarchical naming) influenced how people imagined discoverability.

This is the key historical bridge: the registry idea didn’t start with UDDI. UDDI formalized a need that had already existed for years: a searchable catalog that could connect service names to technical details and ownership.

Browser Scripting Turns Endpoints into Reusable Components

In the same period, browser scripting began to change how developers thought about “integration.” Even before modern AJAX patterns, scripts could:

• Normalize and validate user input before submission (reducing server-side complexity).
• Construct URLs with query strings programmatically.
• Coordinate multi-step flows: collect data in one place, then submit it to a CGI endpoint.

Once the browser became programmable, service calls started to feel more like reusable functions than mere page visits. That mental model—services as composable building blocks—naturally increases pressure for a registry: if you can reuse services, you need a systematic way to find and understand them.

Late in this era, the standardization of the DOM helped define what “programmable” meant in a browser. The W3C’s documentation for the DOM Level 1 Recommendation (published in 1998) is a good snapshot of the web becoming an application platform, not just a document viewer. See the W3C spec here: https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/.

What UDDI Later Standardized (and What 1995–1998 Already Had)

It’s tempting to treat UDDI as a sudden leap forward, but it’s more accurate to see it as a standardized response to patterns that were already emerging by the late 1990s:

1) A need for “Yellow Pages” for services

People already categorized endpoints informally: “search tools,” “reporting scripts,” “order status,” “user lookup.” UDDI would later try to represent that categorization in a structured way.

2) A need for “White Pages” ownership and trust

Even early CGI endpoints had owners, escalation paths, and uptime expectations (formal or not). Developers needed to know who maintained a service and whether it was safe to depend on it.

3) A need for “Technical pages” parameters and protocols

Forms already listed parameter names; query strings had documented keys; servers expected certain encodings. These were proto-contracts. UDDI later attempted to point from discovery to technical description (which, in the web services era, would be represented by formats that weren’t yet common in 1995–1998).

The important nuance for web API history is chronological: 1995–1998 established the integration behaviors (call endpoints, pass parameters, parse responses) while the industry was still experimenting with how to catalog and discover those capabilities at scale.

A Practical Lesson from This Era: “Registry” Often Starts as a List

One of the most repeatable patterns in API history is that formal systems usually start as informal documentation. The mid-1990s web is a clear example:

• First you create a script.
• Then you create a form for it.
• Then someone else wants to reuse it.
• Then you write down how to call it.
• Then you put the link somewhere findable.
• Eventually, that “somewhere” becomes a directory, a portal, or a registry.

If you’re building modern API systems, it’s worth remembering that even today, many organizations reinvent this same progression. If you enjoy seeing how old integration patterns echo in current automation and developer tooling, you might like related explorations at https://automatedhacks.com/.

Where This Fits in the Timeline of Web APIs

By the end of 1998, the web had a mature-enough toolkit to support repeatable service-like integration: standardized HTTP usage, ubiquitous forms, widespread CGI deployments, and increasingly programmable browsers. But “API discovery” still depended on human processes and ad hoc catalogs.

That tension—between increasing integration and messy discoverability—sets the stage for the next waves of API history, where the industry would attempt more formal approaches to describing, publishing, and locating services. UDDI’s eventual emergence makes the most sense when you see it as a response to the unresolved questions that were already present in this 1995–1998 chapter.

FAQ

Was UDDI part of the web in 1995–1998?

Not in the way it’s commonly referenced today. UDDI is associated with a later web services era. In 1995–1998, the important historical point is the need for discovery and catalogs—created by CGI, forms, and early integration—rather than UDDI itself.

How did developers “discover” endpoints before formal registries?

Mostly through internal HTML index pages, shared documentation, directory-like lists on intranets, and word-of-mouth. Discovery was social and manual, which didn’t scale well as the number of services grew.

Why do HTML forms matter in API history?

Forms established a clear input/output pattern: named parameters sent to a URL with an expected response. That pattern is extremely close to what we now call a web API call, even if the payload and response were primarily HTML.

What changed by the late 1990s that influenced later registry ideas?

Two things: (1) more dynamic endpoints meant more integration opportunities, and (2) browser programmability made it easier to reuse those endpoints. Together, those factors increased the need for organized, searchable service catalogs.