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+ years I'm just not sure anymore. If I'm using REST incorrectly (according to this article or others), but getting good results and everyone on the team is aligned, does it matter? I'm willing to have my mind changed this, maybe I'm missing something important

I try not to blame the 'Roy Fielding is right' camp on this. I also try not to blame the "terminology doesn't matter' camp.

There are groups of people using the same terms for different things, and getting into arguments where there could be agreement.

There's a diverse set of people on the spectrum between formally trained and self taught people in software development. Terms can get borrowed from places like academic research and get (mis)applied before they are understood.

The REST in industry software is essentially JSON RPC (no, not that one) mapped to HTTP methods. That's a mouthful, so people just say RESTful, despite it not quite being RESTful according to the original notion of REST.

Yes, industry-RESTful isn't necessarily RESTful according to original Roy Fielding definition, but trying to redefine a widely used industry term is unlikely to win one friends at dinner parties.

I think the problem is primarily if you publish a REST api for commercial consumption on some level. If people depend on your REST api, the "RESTfulness" of it affords you some level of inaccuracy when documenting how things work.

But that said, I'm okay with it not following the spec as long as things are clearly documented to end users. We just went through an issue where a prominent CDN provider exposing a REST API we depend on broke REST in a very important way (i.e. NOT stateless). It's extremely annoying to try and construct clients around nonstandard APIs, and the more REST-y, the less annoying.

The point is to externalize the thinking about the desired nirvana state, so that you don't need to thing about them, when you code your API.

Sure, ideally, but if no one can agree on the spec (as evidenced by the need for these types of articles,) then it's not really saving me much effort is it?

Better to just pick something and go with it, then argue about the spec more

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.

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

Ultimately it's all mostly irrelevant. All it matters is that the contract is specified and preserved and clients can consume services through a specific interface. Furthermore the pervasive use of openapi specs already crystalize the RPC approach to interfaces.

I keep running into this as well. Someone shared a link to a study from last year telling me that AI doesn't make programmers as productive as they think. The study was obviously done months prior to it's release. So evaluating the state AI even further back.

But this didn't seem to concern them. The study said X, therefore it applies to today.

I'm just not sure it's worth it to argue with others about it at this point. Not that I'm 100% all behind AI coding, but I'm just shocked people are still this resistant.

> I'm just not sure it's worth it to argue with others about it at this point.

This is the correct response. Let closed-minded people do their thing. Makes them less competitive against you. There's nothing for you to gain by trying to help them understand what they are missing.

wait, who's being closed-minded?