The list is opinionated. Pieces are included because they shaped the field, because they explain something better than anything else, or because they're the source for an idea you'll see referenced everywhere. Pieces are excluded — even famous ones — when they've been superseded, when they've aged badly, or when their main contribution is captured better elsewhere. The list is dated and revisited. If you think something essential is missing or something here doesn't deserve its place, the contact page has the address.
The foundational texts
Roy Fielding — Architectural Styles and the Design of Network-Based Software Architectures (2000)
The dissertation that defined REST. Most people who cite REST haven't read it; almost everyone who has, walks away with a different and less doctrinaire view of what REST means. Chapter 5 is the core; it's worth the afternoon. The "REST" you meet in the wild is a small subset of what the dissertation describes — reading the source is the only way to understand which constraints were original and which got bolted on later.
RFC 9110 — HTTP Semantics (2022)
The current authoritative spec for HTTP semantics, replacing the older RFC 7230–7235 series. Long, dense, but carefully written. Worth reading once cover-to-cover if you build APIs; worth keeping close as a reference for as long as you do. Pair with RFC 9111 (caching) and RFC 9112 (HTTP/1.1 specifics).
RFC 7807 — Problem Details for HTTP APIs (2016, updated 2023 as RFC 9457)
Short and worth reading directly. Defines the standard JSON envelope for HTTP error responses. Adopting it across your API surface saves every consumer from learning your bespoke error shape. The 2023 update (RFC 9457) folds in clarifications and is the version to cite going forward.
RFC 6749 — The OAuth 2.0 Authorization Framework (2012)
The foundational OAuth 2.0 spec. Read alongside RFC 6750 (Bearer Token Usage) and the more recent RFC 8252 (OAuth 2.0 for Native Apps) and RFC 7636 (PKCE). The original 6749 is showing its age — OAuth 2.1 (currently in draft) consolidates two decades of corrections and security guidance — but every implementation still traces back to it.
RFC 7519 — JSON Web Token (2015)
The JWT spec. Short. Read it before you trust any library's documentation; the gap between what the spec says and what implementations actually do is the source of half the JWT vulnerabilities ever published.
RFC 6455 — The WebSocket Protocol (2011)
The base WebSocket spec. Still current. Useful when you need to know what the protocol actually requires versus what your library happens to do.
The argued-over essays
Joe Gregorio — How to design a good API and why it matters (early 2000s, ongoing)
The original essay arguing that API design is a craft worth taking seriously, with criteria. Hard to find a good single canonical source for this idea now — the arguments have been absorbed into the field — but Gregorio's posts on the AtomPub era are where a lot of working REST conventions originated.
Daniel Jacobson, Greg Brail, Dan Woods — APIs: A Strategy Guide (2011)
Aged, but the framing of APIs as products with strategies (rather than mere technical artifacts) was new at the time and is now the default. Skim the chapters on developer experience and ecosystem; skip the stuff on API monetization, which has all moved on.
Mike Amundsen — RESTful Web Clients (2017)
Less read than it should be. Most "REST" writing is from the server's perspective; this book is from the client's. The chapters on hypermedia clients and on the cost of breaking changes are worth reading even if you'll never build a hypermedia client.
Phil Sturgeon — Build APIs You Won't Hate (2015–2017)
Practical, opinionated, occasionally polemic. Best on the trade-offs that come up daily — pagination, versioning, error handling — that the academic REST literature glosses over. Some specifics have aged but the underlying judgment is solid.
Arnaud Lauret (the "API Handyman") — The Design of Web APIs (2019)
The textbook for the field, if there is one. Long, methodical, sometimes more prescriptive than warranted, but a useful single reference for most of the conventions that have settled out. Good first book if you're new to API design.
The deep technical pieces
Sam Newman — Building Microservices (2nd ed., 2021)
Not strictly an API book, but you can't think clearly about API design without thinking about service boundaries. The 2021 second edition is much improved over the first; the chapters on coupling, on data ownership, and on testing are the ones to read first.
Martin Fowler — Patterns of Enterprise Application Architecture (2002)
Predates the modern API era but contains the patterns the modern API era is built on. Domain Model, Service Layer, Data Transfer Object, Repository — the vocabulary you use without thinking comes from here.
Aaron Patterson — various conference talks on Rails internals
Cited because the way Rails approached API conventions — defaults that are right for 80% of cases, with escape hatches — became the template for "API as part of the framework" thinking that everything from FastAPI to Phoenix has copied. The talks themselves are entertaining and sneakily educational.
Geoffrey Thomas — Webhook signing in practice (Stripe blog, 2017)
The clearest explanation of HMAC webhook signing for a non-cryptographer audience. The conventions described — timestamp + body in the signed string, replay window, secret rotation — became the de facto standard across the industry.
Brandur Leach — various pieces on idempotency, redemption codes, and Postgres at Stripe (2014–2020)
The essays on idempotency keys, on safely consuming webhooks, on database-backed reliability patterns are the source for how to think about retries in production systems. Brandur's blog at brandur.org remains the best single archive for this material; the pieces from his Stripe years are particularly worth reading.
Werner Vogels — Eventually Consistent (ACM Queue, 2008)
The piece that introduced "eventually consistent" as a working idea outside academic distributed-systems literature. The framing it uses — strong vs eventual consistency as engineering trade-offs, not absolutes — is the foundation of how to design APIs whose underlying systems can't promise strong consistency.
The security canon
OWASP API Security Top 10 (current edition, updated periodically)
The shortlist of failure modes that show up in real production APIs. Updated every few years. Read when published; re-read each update. The Broken Object Level Authorization entry alone explains a remarkable percentage of API security incidents that ever happen.
RFC 6819 — OAuth 2.0 Threat Model and Security Considerations
The exhaustive list of what can go wrong with OAuth, with mitigations. Long but worth scanning. Read before implementing OAuth on the server side; consult while debugging anything that smells like an OAuth bug.
Auth0 — JWT Handbook (free PDF, 2018)
Despite being from a vendor, an excellent practical reference on JWT. Specific on which algorithms to avoid, which libraries got which things wrong, and how to think about token lifetime. Some library specifics have aged; the conceptual material is still solid.
Aaron Parecki — OAuth 2 Simplified (oauth.com)
The clearest free explanation of the OAuth 2.0 flows and their differences. Especially good on PKCE and on why the implicit flow is deprecated. The companion site oauth.net is the canonical source for current OAuth-related specs and drafts.
Google's API design guide — security section
Google's published API design guide (linked below) has a section on security that's worth reading on its own. Concrete, specific, and reflects what a company that runs APIs at extreme scale has learned about defending them.
The published style guides
Google API Design Guide
Long, dense, opinionated. Reflects how Google designs internal and external APIs. The sections on resource-oriented design and on standard methods are the most influential outside Google. Worth reading even if you don't follow it; the trade-offs they make are well-explained.
Microsoft REST API Guidelines
Less famous than Google's, but more practical for typical SaaS APIs. The guidance on errors, pagination, and versioning is widely cited and well-tested.
Zalando RESTful API Guidelines
The most opinionated of the major published guides. Some of the rules are arguable; the value is that it forces you to confront the questions explicitly. The "MUST / SHOULD / MAY" structure makes it easy to adopt parts.
JSON:API specification
A complete specification for how to shape JSON over REST. Adopting it removes a lot of bikeshedding; some teams find the conventions too heavy. Worth reading once even if you don't adopt it — the ideas about resource relationships and includes are genuinely good.
The talks worth watching
Stewart Brand — How Buildings Learn (BBC documentary, 1997)
Not about APIs at all, about architecture. But the central idea — that the most successful designs are the ones that anticipate change and accommodate it gracefully — is the single most useful frame for thinking about API versioning and deprecation. The "shearing layers" concept maps directly onto good API stratification.
Rich Hickey — Spec-ulation (Clojure/conj 2016)
The talk on backwards compatibility. The "growth" vs "breakage" framing — that you can grow APIs without breaking consumers if you're disciplined about what you guarantee — is the most articulate single statement of how to think about API evolution. Watch it; the talk is better than any summary.
Werner Vogels — All things distributed (Amazon re:Invent keynotes, various years)
Vogels' keynotes are uneven but consistently include a few points that are worth more than most full talks elsewhere. The recurring themes — that APIs are the contract, that backwards compatibility is forever, that scale changes the design — are made concrete with AWS examples that few other organizations can match.
Mat Ryer — How I write HTTP services in Go (various venues, 2018+)
Specifically about Go but the patterns generalize. The way Ryer thinks about the seams between HTTP handling, business logic, and data access is the template for clean web-API architecture in any language.
The blogs worth subscribing to
Brandur Leach — brandur.org
Mentioned above for specific essays. The whole archive is worth browsing. Long-form, careful, opinionated; the rare engineering blog where every post earns its length.
Lukasz Plotnicki / 8th Light blog (when active)
Cited for the recurring quality of the API-design pieces specifically. Best on the design questions that don't fit easily into "REST vs GraphQL" framing.
Stripe Engineering blog
Less frequent now than it was in the mid-2010s peak, but the historical archive on idempotency, on rate limiting, on API versioning at scale is essential reading. The 2017 piece on backwards-compatible API change at Stripe is the canonical reference.
Twilio Engineering blog
Especially good on the operational side — webhook delivery, status pages, incident communication. Twilio's API surface is the largest commercial example of a webhook-heavy product, and the engineering team writes openly about how it's run.
The Cloudflare blog
Wide-ranging, but the pieces on TLS, DNS, and HTTP/3 are consistently the best free explanations of how those protocols actually work. When something low-level changes in the web's infrastructure, Cloudflare's explainer is usually the one to read first.
The mailing lists and standards drafts
IETF httpapi working group
The IETF group focused on HTTP API conventions: problem details, API catalogs, structured fields. The mailing list is where the next generation of conventions gets argued out. Subscribe and skim; you'll see what's coming a year or two before it lands in vendor docs.
OAuth working group archive
Same idea for OAuth. The drafts that become RFCs go through years of debate here; understanding the arguments is the difference between "I implemented OAuth" and "I understand OAuth."
The honourable omissions — and why
A few things that are often included in lists like this but are intentionally not here:
- "REST in Practice" (O'Reilly, 2010) — useful in its time, but the field has moved past most of its specific guidance. The hypermedia chapters in particular reflect a moment that didn't quite happen.
- Vendor blog posts that are mostly product marketing. Specific posts from API vendors that are genuinely useful are listed above; the rest aren't.
- "REST API Design Rulebook" (O'Reilly, 2011) — the framing as "rules" gets in the way of the trade-offs, and the rules themselves are mixed quality.
- Most "API best practices" listicles. They restate consensus without adding to it. The pieces on this list either originated the consensus or critique it usefully.
Where to go next
For shorter-form reference material on the topics this canon points toward, see the reference. For long-form articles on specific subtopics, see the blog. For the protocol-level documentation that the foundational RFCs above are written about, see How HTTP APIs Work.