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

How did REST come to mean the opposite of REST?

htmx.org

Post reply on HN
Print view View original

11–20 of 393 posts

Re: How did REST come to mean the opposite of REST?

#11

Post by xwdv »

iamthepieman wrote: post #4
lloydatkinson wrote: post #3

At this point I’ve stopped caring about REST. It’s like agile and scrum where everyone says they are doing it but everyone has their own opinion of what’s correct. As long as there’s an OpenAPI spec, sane API routes, and it uses a format that’s easily consumable with a given ecosystem (so pretty much always JSON anyway), and it doesn’t do anything dumb like return 200OK { error: true } then I’m happy with it. Too muc…

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

Because you made an error but you shouldn’t worry everything will be OK.

Re: How did REST come to mean the opposite of REST?

#12

Post by Apreche »

If an API is truly RESTful does that automatically mean it's a high quality API? Does that mean it is functional, performant, reliable, secure, and generally well designed? No. An API can be RESTful and also trash. An API can also be non-REST and be amazing.

Is the author correct in that APIs are inaccurately calling themselves RESTful? Yes, yes they are very correct. Congratulations. Here's a trophy for being correct. Now let's focus on what matters, and that is building software that works and works well, REST or not.

Please dump the pedantry and focus on practicality.

Re: How did REST come to mean the opposite of REST?

#13

Post by fabian2k »

The term is used wrong most of the time now, if you try to be more precise you're likely to confuse people not aware of the original meaning of REST. And there's not a really nice term for JSON-based web API that is as short as REST.

Many web APIs are not REST, but still take at least a tiny bit of inspiration from it. Mostly the resource-based structure, not so much any of the other stuff like HATOAS. In practice the self-describing nature simply isn't useful enough, so most people don't bother.

Re: How did REST come to mean the opposite of REST?

#14

Post by yesco »

iamthepieman wrote: post #4
lloydatkinson wrote: post #3

At this point I’ve stopped caring about REST. It’s like agile and scrum where everyone says they are doing it but everyone has their own opinion of what’s correct. As long as there’s an OpenAPI spec, sane API routes, and it uses a format that’s easily consumable with a given ecosystem (so pretty much always JSON anyway), and it doesn’t do anything dumb like return 200OK { error: true } then I’m happy with it. Too muc…

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

The lead for a project I wasn't working on casually informed me they were doing this a few years ago, the reason for it was nothing complicated, they just hated HTTP status codes and believed it was easier to pretend they didn't exist.

I mentioned that it was frustrating to work with APIs like that since a bunch of tooling relies on status codes, including the browser network tab but they just told me they didn't care. They also made a bunch of other questionable design decisions before leaving, so now I just take it for was it is, a red flag.

Re: How did REST come to mean the opposite of REST?

#15

Post by Marazan »

iamthepieman wrote: post #4
lloydatkinson wrote: post #3

At this point I’ve stopped caring about REST. It’s like agile and scrum where everyone says they are doing it but everyone has their own opinion of what’s correct. As long as there’s an OpenAPI spec, sane API routes, and it uses a format that’s easily consumable with a given ecosystem (so pretty much always JSON anyway), and it doesn’t do anything dumb like return 200OK { error: true } then I’m happy with it. Too muc…

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

200 OK but actually you have an error from a pretend-REST API is my number one "old man yells at clouds" thing that drives me nuts. It is fundamentally disrespectful to the users of the API.

Especially if you have metrics/alerts that are tracking status codes.

Re: How did REST come to mean the opposite of REST?

#18

Post by hasperdi »

iamthepieman wrote: post #4
lloydatkinson wrote: post #3

At this point I’ve stopped caring about REST. It’s like agile and scrum where everyone says they are doing it but everyone has their own opinion of what’s correct. As long as there’s an OpenAPI spec, sane API routes, and it uses a format that’s easily consumable with a given ecosystem (so pretty much always JSON anyway), and it doesn’t do anything dumb like return 200OK { error: true } then I’m happy with it. Too muc…

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

Lots of legacy APIs, and bad practices. In the front-end for instance, response 200 was preferred because of easier handling (back in jQuery and Angular times). These days GraphQL still returns 200 on query error

Re: How did REST come to mean the opposite of REST?

#19

Post by Marazan »

number6 wrote: post #10
iamthepieman wrote: post #4

Earlier quoted context omitted.

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

Different layers: the call to the api was successful on the transport Layer, thus 200. You messed up something in the business logic or you asked for a resource that's not there. While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish. You just asked for something the business end could not deliver. The Protocol is fine with your call.

There's.... There is a whole.set of status codes for exactly those things!

Re: How did REST come to mean the opposite of REST?

#20

Post by jaaron »

Joeri wrote: post #7

The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way"

Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about an interoperable, diverse Internet.

If the distributed application is not developed across distributed organizations, particularly independent unassociated organizations, then the architectural style of REST is overkill for what you intend and you could have just kept using RPC the whole time.

The point of the later RESTful API movement was to create distributed applications that leveraged the underlying architecture principles of the internet within their smaller distributed application. The theory being that this made the application more friendly and native to the broader internet, which I do agree is true, but was never the original point of REST.

That said, xcamvber [1] is right: this is me being an old person fighting an old person battle.

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

Post reply on HN