Beyond REST: What the Next API Paradigm Needs
For years, the API community pushed hypermedia as the natural evolution of web APIs. The pitch was that clients could navigate resources like a human browsing links, making APIs self-discoverable and more resilient to change. Yet hypermedia never gained real traction. The technical ideas were sound enough, but the practical payoff for developers was too marginal to justify the additional complexity. After roughly five years of evangelism at API conferences worldwide, adoption remains minimal. It's safe to say hypermedia won't be the next big thing.
Why REST Remains the Default
Service providers often worry that their backend technology choice will determine user satisfaction. In reality, users care far more about documentation quality and integration ease, as long as the technology isn't actively hostile. Technologies like SOAP and OAuth 1.0 failed because they were heavy and obnoxious—not because they lacked theoretical elegance.
REST succeeds primarily on two fronts. First, interoperability is universal: every mainstream language ships an HTTP client. Second, and more importantly, REST provides useful conventions. URLs typically map to resources, CRUD operations map to verbs like PATCH, and status codes carry meaning. Standard headers handle authentication and encoding. This conventionality lets developers learn an API's patterns once and apply that knowledge elsewhere.
| Action | HTTP Verb | URL |
|---|---|---|
| Create | POST |
/customers |
| Replace | PUT |
/customers/:id |
| Update | PATCH |
/customers/:id |
| Delete | DELETE |
/customers/:id |
The problem is that convention only goes so far. Most APIs are REST-ish rather than REST-ful, and the deviations from the ideal are common enough to matter. For instance, Stripe's resource updates historically used PUT instead of the more appropriate PATCH, and the company's ubiquitous reliance on POST remains for backward-compatibility reasons. Developers still need documentation; convention alone won't save them.
Beyond inconsistency, REST has structural inefficiencies. Resource payloads tend to be bulky because they include entire representations rather than just the fields requested. This often fails to match the data clients actually need, leading to N + 1 query patterns. That's a painful tradeoff for mobile users on constrained bandwidth and high-latency networks, where each extra request carries real cost.
Candidates for the Next Generation
It's quite possible that REST-shaped JSON over HTTP remains "good enough" for the foreseeable future. But given those inefficiencies, several alternatives could plausibly displace it.
GraphQL
GraphQL, developed at Facebook, has attracted significant interest. GitHub's adoption of it for a "big API" added legitimacy, but the more telling signal is organic uptake from smaller companies starting greenfield projects on GraphQL rather than REST.
GraphQL's advantages are real. Built-in introspection enables tooling to navigate an unfamiliar API. Data can be organized into a graph rather than heavy resource representations, letting a client ask for exactly the fields it needs in a single request—a major win for page loads that would otherwise require dozens of REST calls. Service operators also benefit from the explicitness of client queries, which provides visibility into what users are actually attempting.
Still, GraphQL's future involves open questions. Facebook itself hasn't deployed it for a public API, which raises doubts about the company's commitment. It could also suffer hypermedia's fate: the edge over REST might not be compelling enough for the broader developer population.
The more serious concern is developer experience. Using GraphQL means hand-writing query blobs with limited client-side typing. The closest analog is SQL—powerful, but painful enough to maintain directly that most developers reach for an ORM. The same could happen with GraphQL, in which case we'd need to ask whether it truly improved productivity or just shifted the abstraction layer.
RPC and Protocol Buffers
If most APIs are only loosely RESTful anyway—with convention reduced to consistent URLs and basic CRUD—then perhaps REST isn't buying as much as its advocates claim. The ideological elegance matters less than integration ease.
An RPC-based approach using a framework like GRPC generates client libraries across many languages from a single definition. Data travels in protocol buffers over HTTP/2, which gives high transport performance by default for both operators and clients. A well-designed set of methods—e.g., create_charge() or delete_subscription(id)—can provide conventions that rival REST's while mapping more directly to the actions users actually want to take.
Consider the common operation of creating a customer and immediately charging them. In REST that's two round trips (POST /customers followed by POST /charges). An RPC paradigm could roll those into a single method, giving designers flexibility that REST's resource model denies.
The transformative scenario for RPC is ecosystem-wide adoption. If major providers like AWS, GitHub, and Stripe all exposed GRPC services, integration would involve downloading protobuf definitions and writing code immediately—all supporting infrastructure would already be standardized.
Bespoke language-specific clients
Another possibility reframes the problem entirely. If developer experience is paramount, major APIs could move toward hand-maintained client libraries in each language their users care about. This is a significant maintenance burden for the provider.
The payoff is that these libraries can follow each language's native conventions, offering strong compile-time checking. The API client could make it impossible to call without an API key or require an email to create a user. Documentation appears in-language—Godoc for Go, for example—or inline through a competent IDE.
Under this model, the underlying protocol (REST, GraphQL, or anything else) becomes an internal detail chosen by library maintainers. The library could translate calls into REST requests or batch them into GraphQL mutations for efficiency; consumers would never see the difference.
The Value of Convention Isn't Going Away
REST's lasting contribution isn't its architecture—it's the idea that consistency and shared convention make developers more productive. GraphQL, RPC, and bespoke clients have paths to a post-REST world, but success depends on achieving the same ubiquity that HTTP and URL conventions achieved.
A fractured future, with each service speaking a different dialect, would hurt developer experience more than any REST inefficiency. The strongest approach might combine a flexible, efficient protocol like GraphQL on the backend with high-quality, language-specific client libraries that exploit strong type systems to catch integration errors before the first request is made, and offer IDE autocomplete as a path to faster iteration.
