Skip to main content
Everybody talks about REST. Nobody implements REST. And nobody really should. I find it funny how often the term became a very misused buzzword, ignoring it true meaning.

​
TL;DR - What your API needs to be to be RESTful?

It needs to implement HATEOAS. An Wikipedia entry provides a good example how would that look with a example JSON API.
Obviously, if you implement something like that, your kind fellow co-worker reviewing your PR will block you from merging that monstrosity, and may leave an comment that may sound “wtf is this ai slop?”. And it’s because we have a lot of better commonly used solutions in our industry, such as OpenAPI, and in some specific, more complex cases, GraphQL. As for current state, HATEOAS is just more like an academic concept rather than something used in development.
[…]HATEOAS isn’t a good fit for most modern use cases for APIs. That is why after almost 20 years, HATEOAS still hasn’t gained wide adoption among developers. commercetools: GraphQL and REST Level 3 (HATEOAS)

​
Should I forget about REST?

Sort of. But maybe still include it in your resume. Also, in my experience, in tech interviews, most questions about “REST” aren’t about “REST” itself, but about HTTP JSON APIs conventions, knowledge, and best practices, such as:
  • request/response structure
  • idempotency
  • using correct HTTP methods and their meanings
  • naming endpoints correctly
  • comparisons to other API architectures
So studying “REST” related questions might show you if you have any knowledge blanks, but I don’t think there’s any benefit in studying the original Fielding’s papers.

​
This is interesting!

If you’d like to learn more about history of REST, its author complains about REST author complaints about term being misused, an essay by Carson Gross (known from htmx) “How Did REST Come To Mean The Opposite of REST?” and its references provide very good background on that :)