What It Really Means for an API to Be RESTful
What it means for an API to be RESTful
I explain that most developers misunderstand REST, often confusing it with simple JSON over HTTP. True RESTful design requires HATEOAS and hypermedia to create self-descriptive interfaces. By following Roy Fielding's architectural constraints, APIs become flexible and navigable without relying on external documentation or fixed URI structures.
I am sorry, but you do not know what a RESTful API is.
- codinhood
REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this.
To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again?
After 12+ years I'm just not sure anymore. If I'm using REST incorrectly (according to this article or others), but getting good results and everyone on the team is aligned, does it matter? I'm willing to have my mind changed this, maybe I'm missing something important
- cjpearson
Many years ago as a young developer I read Fielding's dissertation, Fowler's writings on the Richardson Maturity Model and even a book (don't remember the title) on the topic. Then I spent the next dozen years creating, reading, updating and deleting JSON APIs.
Problem Details (RFC 9457) are useful and have made an occasional appearance, but actual hypermedia driven APIs with custom media types seem to be non-existent outside of example blog posts. It's much more common to instead see APIs overload lesser-used HTTP status codes with their own domain-specific meanings. But if I'm being honest, this sort of protocol crime almost never caused an actual problem in practice.
The advocacy for "true REST" is missing a compelling argument and useful example of why it would actually be an improvement. Despite its prominence, for over 20 years almost nobody has used this approach. Why is that?
I do still have an aesthetic appreciation for "true REST", but in practice I find the fact that nobody uses it to be mainly useful in ending bikeshedding discussions. Once you understand your API isn't RESTful to begin with, there's no longer any point in arguing if 411 or 412 is the more RESTful status code to use when a user attempts to order a product without specifying a quantity. (Spoiler: neither is correct) You simply send a 400 with Problem Details and call it a day. Ironically, this indifference may make your API just a little bit more RESTful.
- montroser
> You must not store or reuse URI structures in the client. An API could change them without notice, and your client would obviously stop working. Instead, parse the links and follow the relative identifiers (rel).
This part is a complete and total fairy tale. No API consumer wants to operate in a world where the API could "change without notice." In real life, no provider would expect that of their clients, and no client would seriously accept that before every API request, they must first hierarchically rediscover the provider's dynamic url scheme of the moment, in order to traverse down to resource they ultimately want to request.
There has never been any serious commercial or high-traffic API that implemented this. And it's not because "lame corporate tech teams aren't hip to the true meaning of REST" -- it's because "it doesn't actually make sense to do it that way so nobody wants it to work like that."
- prologic
Isn't this well defined already? https://en.wikipedia.org/wiki/REST
> REST (Representational State Transfer) is a software architectural style that was created to describe the design and guide the development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave.
And isn't it always misused, mis-represented basically all the time? Often confused with things that are basically just JSON API(s)?
- mwigdahl
Well, this inevitable flamewar will be a nice change from the pro-AI / anti-AI comment threads, at least...