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

Should we rebrand REST?

kieranpotts.com

Post reply on HN
Print view View original

21–30 of 154 posts

Re: Should we rebrand REST?

#21

Post by goto11 »

slver wrote: post #16
tuxie_ wrote: post #4

The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned…

> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.

The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so".

That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.

Re: Should we rebrand REST?

#22

Post by Gunax »

The term really is a bit too academic to understand for a lot of people who are unfamiliar with API design, but comes down to fairly simple concepts when explained in plain language.

I compare it to how monads have an ivory tower definition (the famous 'A monad is just a monoid in the category of endofunctors!') for mathematicians, but can be explained in practical terms much more helpfully, even if that loses some theory.

Years ago I edited the Wikipedia page--it has always been thorny. The trouble is that the definition of REST is so abstract as to be completely meaningless to the average person reading the article.

If you hate using your finite lifespan on something useful, read the talk page. You will find this same edit war playing out over 10+ years between the theorists ('a style of client-server stateless API design where resources undergo state transitions') and the realists who (mis-) define it as a HTTP api.

Even though the theorists are correct, I think it's important to recognize that Wikipedia is going to be the first source of for literally millions of people. It would be a tragedy to not acknowledge that.

Re: Should we rebrand REST?

#23

Post by goto11 »

rualca wrote: post #3

It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is "hypermedia" the only (or even main) design trait. It's like someone who is entirely unfamiliar with REST feels compelled to make bold statements about traits he doesn't fully grasp.

It is the style of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. Because they are not really REST and don't need to be.

He is not suggesting rebranding the architectural style known as REST.

Re: Should we rebrand REST?

#25

Post by Gunax »

vfc1 wrote: post #10

I don't think anyone cares, really. It's a well established name, people knows what it means a REST-style API. It's not perfect, but nothing is, it's good enough. Let's not change its name, what would be the benefit of it? It would only cause even more confusion for no good reason.

I actually really don't think most people know what it means.

Personally, I was on a team of over 10 devs and I am pretty sure none of us knew what REST really meant (including me at the time).

The author is practically correct--RESTful is so misunderstood that even large companies label their APIs as RESTful when they aren't.

Re: Should we rebrand REST?

#26

Post by zozbot234 »

goto11 wrote: post #20
sergioisidoro wrote: post #11

Rebranding misses the point, because most people who claim to provide a REST API are actually providing web API that completely misses many of the rest principles. What we need to do is retrain everyone to use the more general term "Web API" and reclaim the term "rest" for architecture and design decision discussions.

I think HTTP API is fine. "Web" implies some form of hypertext or hypermedia, but this is not required in a API.

"Web" standards include the Semantic-Web/Linked-Data stack for non-hypertext data, which is highly reliant on REST-like and HATEOAS principles.

Re: Should we rebrand REST?

#27

Post by rualca »

goto11 wrote: post #23
rualca wrote: post #3

It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is "hypermedia" the only (or even main) design trait. It's like someone who is entirely unfamiliar with REST feels compelled to make bold statements about traits he doesn't fully grasp.

It is the style of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. Because they are not really REST and don't need to be. He is not suggesting rebranding the architectural style known as REST.

> It is kind of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's.

First of all, the title of the blog post is literally "should we rebrand REST?"

Secondly, these appeals to rebranding REST APIs is already telling of the author's lack of familiarity and insight into the topic. The concept of RPC-over-HTTP is already widely established, as also the age-old stopgap solutions to REST misnomers and incoherences and buzzword abuses which is the Richardson maturity model

https://martinfowler.com/articles/richardsonMaturityModel.ht...

I mean, look at the date that article was posted. 2010. It's over a decade old. This debate is not new, and is already solved. We know what REST is. We know that HATEOAS is a key part, and one that no one implements. We know that there are plenty of ignorant folks starving to put buzzwords on their CV. We know that most people end up using resource-driven RPC-over-HTTP with no hypermedia or discoverability. Just because a blogger failed to do his homework and happened to feel emboldened to coin new buzzwords that doesn't mean he's making any point at all or providing any value.

Re: Should we rebrand REST?

#28

Post by thih9 »

incrudible wrote: post #18
vfc1 wrote: post #10

I don't think anyone cares, really. It's a well established name, people knows what it means a REST-style API. It's not perfect, but nothing is, it's good enough. Let's not change its name, what would be the benefit of it? It would only cause even more confusion for no good reason.

Nitpickers do care. When they start adding HATEOAS and shoehorning semantics into HTTP verbs to make the API more RESTful, they make everything worse to use. The problem is that REST is a buzzword, so you want to keep the word somehow, but throw out the nonsense.

> Nitpickers do care. When they start adding HATEOAS and shoehorning semantics into HTTP verbs to make the API more RESTful, they make everything worse to use.

Sounds like bad work organisation or bad priorities are a factor too. These same people could as well make sure some other spec is followed to the letter; e.g. email validation logic from another HN submission [1].

[1]: https://news.ycombinator.com/item?id=27263141

Re: Should we rebrand REST?

#29

Post by DonHopkins »

rualca wrote: post #14
DonHopkins wrote: post #9

How about simply using "BEST Practices"? The trademark "YOU'VE TRIED THE REST, NOW TRY THE BEST" is officially abandoned, so that's available. https://trademark.trademarkia.com/youve-tried-the-rest-now-t...

> How about simply using "BEST Practices"? REST is already an architecture style, nothing more than an a set of guidelines to design interfaces in order to ensure you get specific qualities and operational advantages. These articles with bold statements regarding the need to change buzzwords already miss the whole point to begin with, and provide absolutely nothing of value.

That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines, a bold statement to ignore the buzzwords and just do what is currently understood to work the best with today's technologies, whatever buzzwords those practices are currently called, which change over time.

For example: BEST Practices a couple decades ago said to use XML over HTTP, while BEST Practices today say to use JSON over HTTPS.

Plus, it makes you think of eating pizza, instead of sleeping!

https://www.reddit.com/r/theouterworlds/comments/ek4gh5/pizz...

Re: Should we rebrand REST?

#30

Post by EMM_386 »

slver wrote: post #16
tuxie_ wrote: post #4

The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned…

> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.

> I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions.

I've been a software engineer for decades and I am helping a company move from SOAP-based XML services into a more coherent REST-type architecture.

Why would this be a banned technical discussion?

Post reply on HN