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

31–40 of 154 posts

Re: Should we rebrand REST?

#31

Post by bryanrasmussen »

h0h0h0h0111 wrote: post #17
quantified wrote: post #8

I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API mig…

>How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”? Ha if agile is anything to go by, people on LinkedIn will be describing their recruiting process or marketing strategy or breakfast as RESTful

our recruiting process is based on a set of idempotent responses, for example if you send in a cover letter for a full stack position we immediately respond with an email asking you to confirm that you are a rockstar ninja.

Re: Should we rebrand REST?

#32

Post by shp0ngle »

People really misunderstand REST, at least as in the original thesis.

The original thesis was for the web. It was not meant for microservice JSON APIs.

And the web is REST. HTTP, built for web, is REST. The REST principles are integrated in HTTP protocol itself, for I think two decades now.

The arguments "is this API RESTful" are nonsense.

...but yeah the article says the same, now that I actually read it.

...now, let's discuss what "agile" means. Or, maybe not.

Re: Should we rebrand REST?

#33

Post by masklinn »

jayd16 wrote: post #13
masklinn wrote: post #6

Earlier quoted context omitted.

> nor is "hypermedia" the only (or even main) design trait. If you take REST as what it’s original author defined, then it absolutely is. Fielding literally has an article saying so: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > REST APIs must be hypertext-driven If you take REST as what it’s become (a worthless buzzword for HTTP-based APIs) then > REST is neither protocol-specific Is wrong in tur…

>A REST API should not be dependent on any single communication protocol I think hypertext is wider than HTTP as far as this blog post in concerned.

> I think hypertext is wider than HTTP as far as this blog post in concerned.

Yes? Did you wildly misread my comment?

REST is either the original definition, in which it is hypertext-driven and protocol-agnostic, or a worthless buzzword for http APIs which are not hypertext-driven but are very much protocol-specific.

Re: Should we rebrand REST?

#34

Post by wingi »

shp0ngle wrote: post #32

People really misunderstand REST, at least as in the original thesis. The original thesis was for the web . It was not meant for microservice JSON APIs. And the web is REST . HTTP, built for web, is REST. The REST principles are integrated in HTTP protocol itself, for I think two decades now. The arguments "is this API RESTful" are nonsense. ...but yeah the article says the same, now that I actually read it. ...now,…

Yes, REST is simple a sub-set of HTTP. Nothing more.

Re: Should we rebrand REST?

#35

Post by zozbot234 »

wingi wrote: post #34
shp0ngle wrote: post #32

People really misunderstand REST, at least as in the original thesis. The original thesis was for the web . It was not meant for microservice JSON APIs. And the web is REST . HTTP, built for web, is REST. The REST principles are integrated in HTTP protocol itself, for I think two decades now. The arguments "is this API RESTful" are nonsense. ...but yeah the article says the same, now that I actually read it. ...now,…

Yes, REST is simple a sub-set of HTTP. Nothing more.

The article says otherwise, though. Using HTTP verbs properly is not sufficient for an API to be fully REST-based.

Re: Should we rebrand REST?

#36

Post by dw-im-here »

We should rebrand REST to Rest to emphasize that the original meaning is lost and that we just use it as a shorthand for a http like API. When it comes to web it's best to set our standards as low as possible because being right doesn't seem to have any advantage over being wrong wrt adoption.

Re: Should we rebrand REST?

#37

Post by pa7x1 »

goto11 wrote: post #21
slver wrote: post #16

Earlier quoted context omitted.

> 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.

100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint.

I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you anything dropping it is the right thing to do.

Re: Should we rebrand REST?

#38

Post by deaddodo »

EMM_386 wrote: post #30
slver wrote: post #16

Earlier quoted context omitted.

> 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?

I think their point is that REST means nothing beyond “uses HTTP verbs” these days. Most companies/teams can’t even agree on the differences between POST, PUT and PATCH; let alone status codes, payload structure, authentication, etc. So using the term REST will mean something different to every person using it. Similar to how a Ruby, PHP and Python engineer will envision a different architecture if you tell them to build a “backend”.

Re: Should we rebrand REST?

#39

Post by francislavoie »

I've given up on REST and I build all my new APIs with JSON-RPC. https://www.jsonrpc.org/specification Super simple.

I'm not a fan of the complexity things like gRPC introduce to most languages (the PHP tooling is horrible for example), and I really don't like the limitations of HTTP verbs and the box that trying to confirm to CRUD puts you in.

Re: Should we rebrand REST?

#40

Post by bklaasen »

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.

Yeah, I call these types of APIs "JSON over HTTP". More syllables than "RESTful API", but everyone knows what I'm talking about.
Post reply on HN