About this issue
This is the inaugural issue of the digest. The future shape — five sections, briskly written, dated — is sketched in the index page. This first issue is lighter on the "what changed in the past month" framing because we're starting from cold; future issues will lean more heavily on month-over-month delta and less on standing context.
The format we're aiming for: roughly 2,000 words per issue, published the first week of each month. Always dated; always with sourced links to anything claimed; never inflated to fill space when there's nothing material to report.
Standards activity worth watching
OAuth 2.1 consolidation
The OAuth 2.1 effort, which has been progressing through the IETF OAuth working group for several years, is approaching consolidation. The aim is not new features but the consolidation of two decades of corrections, security guidance, and best-current-practice into a single document that supersedes the original 2012 RFC 6749 and its many follow-ups. The most consequential changes from a working-developer perspective: PKCE becomes mandatory for all clients (not just public ones), the implicit flow and resource-owner password credentials grant are formally removed, and bearer token usage in URLs is explicitly deprecated.
For most teams already on best practices, the impact is minimal — the consolidation reflects what disciplined OAuth implementations already do. For teams running older OAuth code, the consolidation is a useful forcing function: the code that doesn't comply with OAuth 2.1 is the code with known security weaknesses. Worth the audit. The current draft is at datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/.
Structured Field Values for HTTP (RFC 9651, late 2024)
Worth flagging because it's underused and increasingly central. RFC 9651 (which obsoletes RFC 8941) defines a small set of typed structures — lists, dictionaries, items with parameters — that HTTP headers can use, with a clear parsing model. The benefit is that headers become parseable in a uniform way rather than each header inventing its own ad-hoc syntax.
The reason this matters now: several of the newer HTTP features — including the Sec-CH-* client hints, the Permissions-Policy header, and the in-progress signature header for HTTP messages — are designed around structured fields. Working APIs that emit custom headers should adopt the structured-field grammar going forward; the cost is small and the long-term interoperability benefit is real.
HTTP Message Signatures (RFC 9421, early 2024)
An IETF standard for signing HTTP messages — analogous to what HMAC webhook signatures do, but standardized and more flexible. It defines which message components are signed, how the signature is computed, and how the signature is conveyed in headers.
Adoption is currently uneven. Some major API providers have started recommending it for new integrations; most existing webhook-signing schemes are still vendor-specific HMAC variants. The standard is good engineering and worth understanding even if you don't adopt it immediately, because the next generation of webhook-signing conventions will probably converge on it. We'll cover the practical implications in a future deep-dive.
Tooling worth knowing about
OpenAPI 3.1 has finally absorbed JSON Schema fully
OpenAPI 3.1 (which has been out for several years now) is the version that finally aligned the OpenAPI schema vocabulary with JSON Schema 2020-12. For teams still on OpenAPI 3.0, the migration is mostly mechanical and pays off immediately: schema validation, code generation, and IDE tooling that handles JSON Schema also handles OpenAPI 3.1 schemas. Validation libraries that worked separately on each format now work on both.
The slow adoption of 3.1 has been driven mostly by lagging tooling support. As of mid-2026 the major code generators, validators, and editors all handle 3.1 well; if your team is still on 3.0 because "the tools aren't ready", that's worth re-checking now.
The "spectral" linter for OpenAPI is mature enough to require
For any team maintaining OpenAPI specs, running a linter in CI is now a low-cost / high-value practice. Spectral (from Stoplight, open-source) has the most active rule set; the built-in OpenAPI rule set catches many of the recurring authoring mistakes (missing descriptions, inconsistent response shapes, undefined security schemes), and custom rules let you encode your own house style.
The mistake worth avoiding: starting with an aggressive rule set on a large existing spec and getting drowned in violations. Start with the recommended rule set as warnings; promote rules to errors as you fix them. Six months in, you have a clean spec and a CI gate that prevents regressions.
Recently-published pieces worth reading
The Cloudflare November 2023 control-plane outage postmortem (still worth re-reading)
Already covered in our own postmortem reading. The original by Matthew Prince at Cloudflare remains a model for honest postmortem writing. The combination of specifics about what failed, candor about what design decisions had been deferred, and committed-to remediations is the standard the rest of the industry should aspire to.
The recurring "is REST dead" debate
Surfaces every year or so. The honest answer remains: REST as a strict architectural style was never widely practiced; REST as a working convention for HTTP APIs is still by far the dominant style and isn't going anywhere. The alternatives — GraphQL, gRPC, tRPC — solve specific problems and coexist with REST rather than replacing it. We covered the trade-offs in REST API Design; the recurring debates online rarely add new arguments.
Fielding's dissertation, twenty-five years on
Worth re-reading periodically. Twenty-five years after publication, the parts that aged best are not the architectural style itself but the framing — the discussion of what design constraints are for, how they trade off against each other, and how to reason about software architectures by the constraints they accept. The HATEOAS chapter is the one that aged worst; the constraints chapter is the one that aged best. Linked in our canon.
Notes on this site
For readers following along: in the past month we've shipped:
- A complete repositioning from "fictional API platform marketing" to "developer publication on web APIs". Most pages were heavily rewritten or replaced.
- Pillar references on REST, GraphQL, WebSockets, and authentication, each in the 2,000–2,500 word range, focused on working developers.
- Long-form pieces on rate limiting, idempotency, webhook design, pagination, and error handling.
- A JWT decoder/validator as the first entry in a planned tools section.
- A curated canon of essential reading for the field.
- The first three pieces in the postmortem readings series.
The next month: more interactive tools, more postmortem readings, and the next digest issue. Suggestions for what to cover are welcomed via the contact page.
Sources and corrections
Items in this digest are sourced as follows:
- OAuth 2.1 status: IETF datatracker, OAuth working group.
- RFC 9651 (Structured Field Values): IETF RFC index, published December 2024.
- RFC 9421 (HTTP Message Signatures): IETF RFC index, published February 2024.
- OpenAPI 3.1: OpenAPI Initiative published specification; tooling status from major implementations' release notes.
- Spectral: open-source project on GitHub, current rule-set documentation.
- Cloudflare postmortem: Cloudflare blog, November 2023.
If we got something wrong or missed something material, please email [email protected]. Corrections are noted in the next issue.