When people talk about healthcare APIs today, they usually mean a clean, resource-based interface where a developer can GET a patient summary, post a medication request, or subscribe to updates. And when they talk about FHIR-based interoperability, they’re talking about an approach that feels “native” to the modern Web: URLs, standard HTTP methods, and predictable data formats.

But that way of thinking didn’t start in healthcare. It didn’t even start with “APIs” as a mainstream Web term. It started with a simple idea that took off between 1990 and 1994: the Web as a universal, networked, client-server information space. In this chapter of web API history, we’ll look at how early HTTP interfaces and the first wave of Web servers quietly created the pattern that healthcare would eventually adopt—years later—through FHIR.

The early Web wasn’t an “API platform,” but it behaved like one

In the early 1990s, the World Wide Web emerged from research contexts into wider academic and institutional use. HTTP was deliberately simple at first: a client made a request, a server returned a response. That sounds obvious now, but at the time it was a dramatic shift from many closed, proprietary, or heavyweight network systems.

Even before developers used the term “web API,” early Web interactions already had several API-like traits:

• Uniform addressing via URLs, which acted like stable identifiers for “things.”
• Standard verbs (primitive at first, later more formal) that implied a consistent interaction model.
• Stateless request/response behavior that reduced coupling between client and server.
• Intermediary friendliness (proxies, gateways, and later caches) that helped systems scale beyond direct point-to-point connections.

This matters for healthcare because interoperability is essentially an argument about interfaces: How can two systems agree on identifiers, payloads, behaviors, and error handling without endless custom integration work? The early Web did not solve healthcare’s domain semantics (what is a “problem list” or a “medication statement”?), but it demonstrated a practical, repeatable transport pattern.

1990–1994: The “interface” starts to separate from the “application”

Between 1990 and 1994, Web architecture began to encourage a separation that becomes crucial for APIs: the idea that an endpoint is something you can call, not just something you look at.

In practice, early endpoints were often just files: HTML documents on a server. But the second-order effect was bigger: once you can request a resource by URL, you can also imagine requesting a computed result, not just a static page. That is where Common Gateway Interface (CGI) scripts (and similar techniques) became influential. CGI wasn’t “REST,” and it wasn’t standardized as an API style guide. But it established something that future API builders would rely on: server-side code triggered by HTTP requests, producing structured responses (initially HTML, and later many other formats).

In healthcare terms, this is the moment when “the network” begins to look like a universal integration surface. Prior to that, healthcare integration tended to happen through specialized message transports, custom interfaces, and hub-and-spoke middleware. Those methods were effective, but they were often vendor-specific and operationally heavy.

What healthcare interoperability looked like in the early 1990s

In the 1990–1994 timeframe, healthcare data exchange was already happening—just not primarily via the Web. Organizations used established messaging standards, and HL7 v2 was a major force in clinical messaging. The typical integration story involved admission/discharge notifications, lab results feeds, and interface engines translating between systems.

What the Web changed was not the existence of interoperability needs, but the expectations around how interoperability could feel to developers and operators:

• Self-service discovery: a URL you can try is more approachable than a bespoke socket protocol or a proprietary client library.
• Cross-platform access: a browser demonstrated that one client could talk to many servers without custom installs.
• Incremental rollout: you could publish small slices of functionality without migrating everything at once.

It would still take years before healthcare broadly trusted the Web for sensitive clinical workflows. Security, authentication, and auditability were real constraints. But the early Web established the core interaction shape that FHIR later embraced: treating health data as addressable resources accessed via a consistent HTTP interface.

The first lessons that foreshadowed “FHIR on the Web”

FHIR is often described as “modern web standards applied to healthcare.” That description only makes sense because the Web’s early era built a recognizable set of expectations. From 1990 to 1994, several lessons emerged that map cleanly to later healthcare API design:

1) URLs became the de facto integration contract

Even when payload formats were inconsistent, the URL acted as a contract: it named the thing you were asking for. Over time, this became the foundation for stable identifiers. FHIR later uses URLs (and URL-like identifiers) heavily—both for RESTful endpoints and for defining canonical resources and profiles.

2) Statelessness made systems easier to combine

Healthcare workflows are often stateful (orders, results, reconciliations), but stateless transport reduces the brittleness of integrations. Early HTTP interactions leaned toward statelessness, encouraging clients to provide what they needed on each request. FHIR benefits from the same principle: requests are self-contained, and servers can scale and evolve more safely.

3) Text-based protocols lowered the barrier to entry

HTTP’s human-readable nature made debugging and experimentation easier. That developer experience advantage matters in healthcare, where integration projects can stall under complexity. The eventual popularity of JSON and approachable tooling for HTTP APIs built directly on this early culture of “you can inspect the wire.”

4) A shared protocol created a shared ecosystem

As the Web expanded, the value wasn’t just in any single server or client—it was the interoperability of the ecosystem. FHIR’s strategy echoes this: succeed by creating a shared interface that many systems can implement, enabling a marketplace of apps and services rather than one-off point integrations.

Why this era matters for today’s healthcare API conversations

If you’re implementing FHIR now, it can be tempting to treat its web orientation as obvious. But historically, it represents a long convergence: clinical data standards meeting the Web’s interface discipline.

The 1990–1994 period is the “birth of the Web” chapter in that convergence. It’s when HTTP proved that a lightweight, general-purpose interface could scale to many organizations and many use cases. Healthcare would later bring the hard part—domain semantics, privacy, safety, and correctness—but it didn’t need to reinvent the transport and interface patterns from scratch.

One practical takeaway for modern teams is that interoperability isn’t only about the data model (though that’s critical). It’s also about operational simplicity: predictable endpoints, stable addressing, and uniform behaviors. Those are lessons the early Web learned in public, through rapid experimentation.

If you’re mapping this history forward into modern automation and integration practices, you may also enjoy related engineering perspectives at Automated Hacks, especially where API design intersects with reliability and scalable tooling.

A quick note on standards and how to read them

To understand why the early Web was such a strong foundation for later API styles, it helps to read primary materials about HTTP and related protocols. The W3C’s protocol documentation is a solid starting point for understanding the Web’s standards lineage and how the protocol family fits together. See: W3C Protocols (including HTTP).

FAQ