July 30, 2026
REST in pieces, comment section
What it means for an API to be RESTful
Turns out your ‘proper’ web API might not be the real deal, and the comments got spicy
TLDR: The article argues that most “REST” web systems aren’t following the original rules and that truly proper ones should guide software through built-in links. Commenters instantly turned it into a drama fest, split between pedants, jokers, and cynics who think the term is already too mangled to save.
A developer dropped a classic internet grenade this week: “you probably don’t actually know what a truly proper web API is.” The article tries to rescue the term from years of misuse, arguing that most so-called “REST APIs” are really just websites for computers that send data back in a convenient format. The big reveal? A real REST-style system, according to the original definition, should let software discover what it can do next through built-in links, instead of forcing humans to read piles of outside documentation.
And oh, the crowd was ready. One commenter immediately predicted an “inevitable flamewar,” sounding almost relieved to swap the usual AI shouting matches for a fresh nerd battle. Another went full comedy mode with “GET /api/add-a-comment?message=disagree,” which is basically programmer stand-up: one line, maximum shade. Others were less amused and more exhausted. One person basically said, “Isn’t this already settled?” while linking the Wikipedia entry on REST. Another brought the real purist energy, pointing out that these helpful links don’t even need to be inside the response body at all—they can live in headers too, because of course there’s another layer to argue about.
The hottest take, though, came from the cynics: if a word has been stretched so far that nobody agrees what it means anymore, maybe the word is just broken. So while the article tried to define the truth, the comments turned into a very online referendum on whether truth in tech naming is even possible.
Key Points
- •The article defines REST as an architectural style created by Roy Fielding in 2000, not simply an HTTP API.
- •REST is described through constraints including client-server separation, statelessness, cacheability, layered systems, uniform interface, and optional code on demand.
- •The article says industry usage often mislabels JSON-over-HTTP APIs as REST, even when they do not satisfy stricter REST requirements.
- •It uses the Richardson Maturity Model to distinguish API maturity levels and states that most so-called REST APIs stop at level 2 rather than level 3.
- •The article presents HATEOAS and hypermedia links as the core feature that makes a RESTful API self-descriptive and navigable without external documentation.