HTTP 1.1 is the bedrock that the entire web API economy is built on, and I don’t think most people in the API space fully appreciate how much they owe to it. When we talk about REST APIs, web APIs, the API economy — all of it runs on HTTP, and for the vast majority of the modern API era, that has meant HTTP 1.1. It’s the protocol that defines how clients and servers talk to each other over the web: the methods (GET, POST, PUT, DELETE), the status codes (200, 404, 500), the headers, the request-response cycle. Every time a developer makes an API call, they’re using HTTP, usually 1.1, whether they think about it or not. The genius of the web API movement was recognizing that we didn’t need to invent a new protocol for machine-to-machine communication — we could just use HTTP, the protocol the web already ran on, the way it was designed to be used.
This is the insight at the heart of REST, and it’s why I’ve always said I believe in the web. When I wrote in 2017 that I’m not a card-carrying RESTafarian, I just believe in the web, I was getting at exactly this: the value of REST isn’t in dogmatic adherence to architectural constraints, it’s in using HTTP properly — using the verbs the way they’re meant to be used, returning the right status codes, leveraging content negotiation and caching and the other capabilities HTTP 1.1 already provides. Roy Fielding’s REST dissertation described the architectural style that made the web work, and that style is fundamentally about using HTTP as designed. The web APIs that won did so by embracing HTTP rather than building heavyweight protocols on top of it the way SOAP did. HTTP 1.1 was already there, already everywhere, already understood — and the API movement’s great move was to just use it.
The “website is the API” idea captures how foundational HTTP 1.1 is to the whole vision. I wrote in 2011 about services where the website is the API — where the same HTTP requests that return HTML to a browser can return JSON or XML to a machine through content negotiation. This is HTTP 1.1 working as intended: the same URL, the same protocol, serving humans and machines based on what they ask for in their headers. The programmable web that I’ve evangelized since 2010 is fundamentally an HTTP phenomenon — the recognition that everything accessible on the web through HTTP could also be accessible to machines through the same protocol. HTTP 1.1 made the web programmable because it was already the universal language of the web, and APIs just taught machines to speak it.
The durability of HTTP 1.1 is remarkable, and it’s worth dwelling on because it explains so much about the API world’s stability. HTTP 1.1 was standardized in 1997 and has remained the workhorse of web APIs for the entire modern era. Tools like curl, which I wrote about in 2025 with genuine admiration, have been speaking HTTP for a quarter century and just keep working. The reason almost every API documents itself with a curl example, the reason every developer’s first API call is an HTTP request, the reason the whole ecosystem of API tooling assumes HTTP — all of it traces back to the stability and ubiquity of HTTP 1.1. It’s the lowest common denominator that everything else builds on, and its very boringness is its strength. A protocol that just works, everywhere, for decades, is the kind of foundation you can build a global economy on.
The text-based simplicity of HTTP 1.1 is a feature that mattered enormously for adoption, even as later versions traded it away for performance. HTTP 1.1 is human-readable — you can read a request and a response, understand them, debug them, craft them by hand. This human-readability is a huge part of why web APIs were so much more accessible than the binary protocols that preceded them. A developer could see exactly what was happening on the wire, learn from it, and build with it. This is the same quality that I noted when contrasting REST with gRPC’s binary efficiency: HTTP 1.1’s text-based, human-readable nature is slower and less efficient than binary alternatives, but it’s dramatically more accessible, and accessibility is what drove the API economy. The protocol’s simplicity was its superpower.
The honest framing is that HTTP 1.1 is the unglamorous foundation that everything depends on, and recognizing that is its own kind of API wisdom. I wrote in 2024 that REST is a mess, just like us humans — and part of what I meant is that the HTTP-and-JSON foundation of web APIs is imperfect, inconsistent, and messy, but it works and it’s universal, which matters more than elegance. The internet standards work that APIs rely on, which I wrote about in 2025, mostly happens invisibly — the IETF’s careful stewardship of HTTP is foundational infrastructure that the API world benefits from without thinking about. HTTP 1.1 is the protocol nobody talks about because it just works, the substrate beneath REST and the web API economy, the thing that made the programmable web possible by already being the universal language of the web. The later versions — HTTP/2 and HTTP/3 — improve on its performance, but they’re evolutions of the same fundamental model that HTTP 1.1 established: clients and servers exchanging requests and responses over the web, using methods and status codes and headers, in a way that’s universal enough to build an entire economy on. That foundation is HTTP 1.1, and the whole API world rests on it.
References
- API Technology: REST
- With Seevl Music Discovery, The Website Is The API
- I Am Not A Card-Carrying RESTafarian, I Just Believe In The Web
- Delivering Large API Responses As Efficiently As Possible
- REST Is A Mess, Just Like Us Humans
- The Internet Standards Work APIs Rely On That Does Not Always Get The Spotlight
- curl And APIs
- HTTP APIs Provide Awareness Around Who Is Using Your Digital Resources
- The Web And APIs Weren’t Built For Autonomous Agents, They Were Built For Humans
