Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What it means for an API to be RESTful

en.andros.dev

Post reply on HN
Print view View original

41–50 of 59 posts

Re: What it means for an API to be RESTful

#41

Post by chasingthewind »

I was a REST purist for a while and the purer I got the more unhappy I was. Hypermedia standards like Siren and HAL just made things miserable no matter how hard I tried to make them work.

I think the REST Architectural Pattern is great but I don't use it anymore. Instead I create ROUSED services.

  Resource
  Oriented
  Unconstrained
  Sensible
  Enterprise
  Services
Resource Oriented because the very best thing about REST is the tendency to focus on resources and collections of resources and how you can interact with them sensibly.

Unconstrained because I don't let some specification control how I work.

Sensible because things still need to be internaly consistent and well thought out.

Enterprise because the fact is I'm always making these services for some 'boring' business use case.

Services that provide some specific set of bounded capabilities within the usual messy ecosystem present at a SaaS software company.

I think we owe a lot to Roy Fielding for the potent ideas but as others have argued eloquently, reality sets in and you have to adapt to circumstances.

Re: What it means for an API to be RESTful

#42

Post by andros »

locknitpicker wrote: post #37
codinhood wrote: post #19

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…

> 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. Yes, and this blog post is exactly yet another example. Some of the blogger's points are blatant violations of REST, such as the comments on URIs and api versioning. Yet, the blogger elevates their own personal misconceptions to the status of one true RESTful way. U…

[flagged]

Re: What it means for an API to be RESTful

#43

Post by andros »

mwigdahl wrote: post #7
janpio wrote: post #4

Earlier quoted context omitted.

Are you sure it is not just a AI authored rehash of the thousands of articles online that make the same points already?

Nice! Not 100% sure, but it reads very human to me. The only LLM-ism that jumped out at me was "An honest note before we continue", but that was the only time the word "honest" appeared. If it's not human-written it does an exceptionally good job of appearing so.

Let me clarify: this was written by one person, by me. However, I received help with spelling mistakes, false friends, and a few connectors. Thank you!

Re: What it means for an API to be RESTful

#45

Post by andros »

recursivedoubts wrote: post #15

Here is how REST came to mean the opposite of REST: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... And here is why REST is probably largely pointless in machine-to-machine APIs: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

A few years ago I would have 100% agreed with you, but now with LLMs they may have made sense again.

Re: What it means for an API to be RESTful

#46

Post by [deleted] »

locknitpicker wrote: post #37
codinhood wrote: post #19

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…

> 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. Yes, and this blog post is exactly yet another example. Some of the blogger's points are blatant violations of REST, such as the comments on URIs and api versioning. Yet, the blogger elevates their own personal misconceptions to the status of one true RESTful way. U…

[deleted]

Re: What it means for an API to be RESTful

#47

Post by 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."

Re: What it means for an API to be RESTful

#48

Post by gwbas1c »

Every time I look at a "how to do pure REST", it seems like doing REST correctly is building a self-describing database instead of making an API that does a thing.

Here's the thing:

Customers don't care if your application does REST correctly or not. They only care if your application works.

API consumers care about REST only as far as the HTTP API makes sense and follows well-known and well-understood conventions.

I don't think I've ever come across a self-describing API in the wild where I have to constantly self-discover URIs. (And frankly, if someone proposed something like this I'd laugh at them.) It's just needless overengineering.

Re: What it means for an API to be RESTful

#49

Post by recursivedoubts »

andros wrote: post #45
recursivedoubts wrote: post #15

Here is how REST came to mean the opposite of REST: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... And here is why REST is probably largely pointless in machine-to-machine APIs: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

A few years ago I would have 100% agreed with you, but now with LLMs they may have made sense again.

yes, I caveat that at the end:

> Once we have strong AI, maybe the situation changes. But that’s what we’ve got today.

However, I am doing research on AI and hypermedia and I'm skeptical that the late-bound, discoverable dynamic of it compete well with things like MCP, at least if you are using something like a ReAcT loop.

I am publishing a paper on this soon.

Re: What it means for an API to be RESTful

#50

Post by lofaszvanitt »

codinhood wrote: post #19

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…

During job interviews, when someone asks me to tell the TOP 10 entries of OWASP and the basics of RESTful, I'm ready to jump out of the window :D.
Post reply on HN