The central theme of this article is that most APIs labeled as "RESTful" today diverge significantly from Roy Fielding's original concept of REST, primarily by omitting the use of hypermedia to drive application state, a tenet known as HATEOAS. Rather than equating REST with CRUD operations over HTTP, Fielding defined REST as an architectural style centered on clients discovering actions and transitions through dynamically provided links in resource representations. The article highlights that the widespread misunderstanding and misuse of the term “RESTful” reduces it to conventional HTTP contract-based APIs, missing the architectural benefits envisioned by Fielding.
A deeper examination reveals that APIs widely considered RESTful typically fail several key constraints Fielding laid out—especially in making hypermedia the engine of application state. Many real-world implementations opt for simpler, static interfaces, sidestepping the complexities of hypermedia controls, protocol-independence, standardized media types, and dynamic link navigation. This trend is driven by practical challenges, including steep tooling and developer experience barriers, as well as the demands of tightly integrated frontends and backends, where leaner, more predictable interfaces often trump architectural purity. Ultimately, the article advises that API designers weigh context and consumer needs over dogmatic adherence to REST, leveraging hypermedia only when its advantages will be realized.
Hacker News commenters predominantly agree that the common use of “RESTful” is a misnomer, echoing Fielding’s own frustration with APIs that neglect hypermedia and reduce REST to “HTTP with JSON.” The discussion further explores the nuanced distinctions between conceptual resources, actual REST constraints, and the realities of modern web development. Many highlight that the cost and complexity of implementing full HATEOAS are seldom justified, noting that for many use cases, pragmatic RPC-style APIs are preferable. Commenters also provide actionable suggestions, such as considering hypermedia for public or evolving APIs, but not for tightly coupled internal services, reflecting a broad consensus that clarity and loose coupling, rather than terminology, should guide API design.