Live data from Hacker News

It's time to put REST to rest

sollecitom.github.io

21–30 of 85 posts

Re: It's time to put REST to rest

#21

Having used “REST” for 10 years or so I can confidently say I’ve never used REST

The three common types of "REST" I have encountered in enterprise dev are:

1. Ancient XML/SOAP based APIs Frankenstiened to use JSON

2. Poorly implemented RPCs advertised as "JSON REST API", usually the entire thing either relies on POST requests but sometimes GET is used to make stateful changes.

3. Things that should obviously be RPC split into dozens of anemic JSON endpoints that the caller has to re-construct to get anything useful

Incidently, my company's leadership got inspired by Amazon's API culture and made # of APIs a metric that teams must hit. The result is every single endpoint being deployed as a separate API, and teams blocking access to native vendor APIs so each operation can be republished as a new API. :)

Re: It's time to put REST to rest

#22

Having used “REST” for 10 years or so I can confidently say I’ve never used REST

Yea. I assume from the article it's an alias for an HTTP interface that usually uses JSON payloads. I use those in a few projects, both work and personal. Are they Rest? Maybe. They use Django REST framework. But I think of them and describe them as HTTP APIs.

Well, if we're being truthful, none of us use REST. We're all just cherry-picking the parts of it that work for our organizations... and that's absolutely fine. The programtic discoverability portion of REST always struck me as pretty poorly thought-out anyways.

Re: It's time to put REST to rest

#23

OK OK OK, OK OK, stay calm, Carson, stay calm... I'd like to just leave a few links on REST here for the reader's consideration: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-clients/ https://intercooler…

Thank you! Exactly my thoughts. I stopped using the term REST because in web development circles it’s meaningless. I use Hypermedia API.

Re: It's time to put REST to rest

#24
Rest is fine, just a loose standard around using HTTP for rpc calls. Makes communicating between different servers and languages easy.

The real mistake is graphql. Like microservices, so many companies get hamstrung with this. I’ve said my piece.

Re: It's time to put REST to rest

#26

I’ve been having a good time using REST level 0.5 https://faithlife.codes/blog/2023/09/rest-level-zero-dot-fiv...

Interesting! Level 0.5 seems to be what twirp[1], which I have used and enjoyed, would also fall under.

[1]: https://github.com/twitchtv/twirp

Re: It's time to put REST to rest

#27
post #22

Earlier quoted context omitted.

Yea. I assume from the article it's an alias for an HTTP interface that usually uses JSON payloads. I use those in a few projects, both work and personal. Are they Rest? Maybe. They use Django REST framework. But I think of them and describe them as HTTP APIs.

Well, if we're being truthful, none of us use REST. We're all just cherry-picking the parts of it that work for our organizations... and that's absolutely fine . The programtic discoverability portion of REST always struck me as pretty poorly thought-out anyways.

You use REST every day. HTML is REST. Yes, with HATEOAS.

Re: It's time to put REST to rest

#29
It drives me crazy that every RESTful API I've ever seen in the wild has been running under a full-blown Tomcat or nginx (or some equivalent) web server when only a tiny, tiny subset of the HTTP protocol is actually needed for the API being supported.

Re: It's time to put REST to rest

#30
post #4

If I had to guess, the comments here are going to revolve around "that's not REST" and "where's the hypermedia." I think that ship has sailed. REST in practice just means following HTTP semantics.

Exactly. If you ditch the bikeshedding and no true scot arguments, REST is just a loosely defined naming convention around HTTP verbs, that almost every company I have been apart of agrees on / disagrees on certain minor aspects. That being said, I am thankful that we moved to using some form of "REST" (however you define it) as it was infinitely better than WSDL/SOAP. gRPC is nice in some areas, but these days I fin…

If you define the terms exactly the way I want, then I win the argument! It's a very useful technique.
Post reply on HN