When developers talk about embeddings APIs and semantic search today, the conversation usually starts with vector databases, transformer models, and endpoints that accept text and return arrays of floating-point numbers. But if you trace the chronological history of web APIs far enough back—into the Web’s earliest public years—something surprising appears: the basic interaction pattern behind modern semantic search was already taking shape between 1990 and 1994.

Not the machine learning, of course. The early Web didn’t have hosted models or JSON payloads. What it did have was a rapidly standardizing idea: a network-accessible interface where a client makes a request with parameters, the server performs a computation (often search), and the server returns a result the client can render or post-process. In other words: the Web began inventing “API-shaped” software, even before the term “web API” became common.

This chapter focuses on the birth of the Web and early HTTP interfaces—especially the URL query and CGI “gateway” era—and shows how those design decisions became the ancestor of today’s embeddings-based retrieval pipelines.

1990–1991: The Web’s first interface was already an API

At the dawn of the Web, the most important “API” wasn’t a library—it was a protocol. Early HTTP (often discussed as HTTP/0.9 in retrospective histories) established a minimal request/response structure: a client asks for something by name, and a server replies with a representation.

That sounds basic now, but it did two profound things for API history:

1. It normalized remote procedure by naming: even when you weren’t calling a function, you were invoking a server-side behavior by selecting a resource path. That mental model—“a URL triggers server logic”—became the foundation for early search endpoints.
2. It pushed statelessness into the mainstream: each request could stand on its own. You didn’t need a long-lived session just to fetch the next piece of information. Modern embeddings APIs inherit this: you send text, you get vectors back, and the call is complete.

At this time, “semantic search” wasn’t framed as AI. It was framed as information retrieval: ranking documents by relevance rather than strict matching. That field had mature ideas well before the Web, including vector-space representations of documents and queries. Even if early web servers weren’t generating embeddings, they were building habits of remote querying and computed responses.

1992–1993: URLs turned into parameterized query interfaces

One pivotal shift in early web API history was the move from “fetch a static document” to “request a computed answer.” The Web needed a way to ask questions like:

• Search this index for a term.
• List resources in a category.
• Return documents matching certain criteria.

Before JSON bodies and POST requests became everyday tools, the easiest mechanism was right in the URL: a query string. The pattern is familiar even now:

/search?query=hypertext&scope=all

In the early 1990s, this was a breakthrough because it let a hyperlink represent not only a document, but an action with arguments. A link could become a button. A URL could become a callable interface.

This matters for semantic search history because relevance ranking depends on parameters. Even basic retrieval systems need inputs like query terms, constraints, and sometimes weighting. The Web’s parameterized URLs became the simplest “call syntax” for search before formal web service conventions existed.

During these years, the Web also gained momentum through early browsers (notably Mosaic in 1993), which made HTTP-based navigation and linking widely approachable. As usage expanded, the need for indexing and discovery intensified—pushing more server-side querying onto HTTP endpoints.

CGI: the original web “gateway” to computation

If one technology from this era deserves credit as an ancestor of today’s hosted AI endpoints, it’s the Common Gateway Interface (CGI). CGI wasn’t a single product. It was a convention that let web servers run external programs to produce dynamic responses.

In practice, CGI turned the Web server into a universal adapter:

• The client sends an HTTP request.
• The server maps it to a CGI script or executable.
• The program reads inputs via environment variables and standard input.
• The program writes an HTTP response (headers + body).

From a modern perspective, that’s uncannily close to how an embeddings API works operationally: a request arrives, code loads a model or calls a service, a vector (or ranked list) is computed, and a response is returned. The big difference is packaging (HTML then, JSON now) and infrastructure (single host processes then, distributed cloud now).

CGI also encouraged a crucial piece of API design thinking: clear boundaries. The web server didn’t need to know how search worked; it only needed to hand the request to a program. That modularity is the same reason modern teams can swap one embedding model for another behind an endpoint without breaking callers—if the interface contract remains stable.

Early search systems: “semantic” without embeddings

Between 1990 and 1994, “search” on the internet wasn’t a single thing. Several systems emerged across different protocols and content types. What they shared was a growing expectation that you could ask the network a question and get back a computed result—an API-like interaction.

A few historically important examples from this era include:

• Archie (commonly cited around 1990) for indexing FTP archives.
• Veronica and related tools (early 1990s) for searching Gopher menus.
• Early Web indexes in the 1993–1994 period as the Web expanded and directories/search services began to appear.

While these weren’t “embeddings” in the deep learning sense, they often relied on information retrieval approaches that resemble today’s semantic pipeline at a high level:

1. Represent content in a searchable form (then: term statistics; now: dense vectors).
2. Represent a query in the same space (then: weighted term vector; now: query embedding).
3. Rank results by similarity (then: cosine similarity or related scoring; now: nearest-neighbor search over embeddings).

The key point for web API history is that the Web offered a universal transport and naming system for these retrieval operations. A “search URL” became a durable interface, and once you have durable interfaces, you get composition: other tools can build on top of them, cache them, link to them, and automate them.

Why this era matters to embeddings APIs specifically

Modern embeddings APIs usually look something like this conceptually:

• POST text to /embeddings
• Receive a vector
• Store vectors in an index
• At query time, embed the query and retrieve nearest neighbors

None of that infrastructure existed on the early Web. Yet several architectural expectations that embeddings APIs rely on were forged in 1990–1994:

1) The uniform interface idea

HTTP’s simplicity encouraged a “uniform interface”: clients don’t need custom protocols per service. They use the same verbs/requests and learn the service by reading documentation. Even today, embeddings providers compete on latency and quality, but they share the same basic web-facing shape: HTTP requests over standard ports with standard authentication patterns.

2) Parameter-driven computation

Search and retrieval depend on parameters. Early query strings were a primitive but powerful way to capture a function call in a link. That idea matured into well-designed query APIs and eventually into JSON request bodies.

3) The separation of representation and meaning

Early web search taught developers that the document a user reads and the representation a machine searches aren’t the same. Today, embeddings are an even stronger expression of that: the “meaning representation” is a vector, not the visible page.

In other words, the Web’s first few years didn’t invent embeddings, but they did invent the network habit of calling computation through HTTP. That habit is what makes “embedding as a service” feel normal today.

Reading early HTTP with modern eyes

If you’re building semantic search now, it’s worth revisiting HTTP fundamentals—not as trivia, but as design guidance. Many modern failures in embeddings-powered search come from interface sloppiness: unclear inputs, inconsistent response schemas, and endpoints that are hard to cache, monitor, or evolve.

HTTP’s durable lessons—stateless requests, explicit headers, and layered architecture—are still the best antidote to those problems. For a concise, authoritative refresher on how HTTP works in contemporary terms, see the MDN overview here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview.

And if you’re thinking about how to automate the “glue” around embeddings—crawling content, chunking text, building indexes, and measuring retrieval quality—keep your implementation grounded in API-first thinking. Practical automation insights and experiments often start with a small, testable HTTP interface. You can find more applied work along those lines at https://automatedhacks.com/.

What changed after 1994 (and why this chapter stops here)

By 1994, the Web’s growth was forcing more standardization and clearer developer conventions, setting the stage for more formal specifications and, eventually, web service styles that would be recognizable to modern API builders.

This chapter stops at 1994 because the point isn’t to claim the early Web “had embeddings.” It didn’t. The point is that the Web’s first wave of HTTP interfaces—especially query URLs and CGI—created the shape of remote computation that later made semantic services feel inevitable: search endpoints became normal, ranking became expected, and developers learned to treat HTTP requests as programmable building blocks.

When embeddings arrived decades later, they didn’t have to invent the interface. The interface was already waiting.

FAQ: Embeddings APIs and semantic search in the early Web era

Were there embeddings in 1990–1994 web APIs?

No. Modern neural embeddings and hosted embeddings APIs are much later. However, information retrieval methods that represent text as vectors (in the classic term-weight sense) existed before and during this period, and the Web began exposing search-like computation through HTTP interfaces.

Why is CGI relevant to today’s AI and embeddings endpoints?

CGI popularized the pattern “HTTP request in, computed response out” via a stable interface boundary. That’s conceptually similar to calling an embeddings service: a network request triggers computation and returns a structured result, even though today’s payloads and infrastructure are far more advanced.

What’s the biggest API-design lesson from 1990–1994 for semantic search builders?

Keep interfaces simple and durable. Early HTTP succeeded because it was minimal and interoperable. Embeddings systems are complex internally, but the external API should be consistent, well-documented, and stable enough that callers can build automation around it.

How did “semantic search” exist before modern AI?

Semantic search can mean “retrieval by relevance” rather than literal string matching. Classic information retrieval techniques used weighted term representations and similarity scoring to approximate meaning. Modern embeddings improve this by using dense vector representations, but the goal—finding conceptually relevant documents—predates the Web.