[anamexis]

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.

[dimitrios1]

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 find myself doing what the article says more often than not -- just creating business-definition specific resources that utilize GET/POST and JSON.

[yawaramin]

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

[dimitrios1]

yawaramin, my former reasonML brother, you won't remember me, but I am so happy to have you comment on my comment even if it is tongue in cheek! Hope all is well.

[yawaramin]

ReasonML–that brings back good memories! :-D

To be honest, I was pulling your leg but I mostly do the same thing you're doing when dealing with APIs at work :-P

[troupo]

> REST in practice just means following HTTP semantics.

If that were true, it would be awesome. Because full HTTP semanics are quite intricate, and cover a lot

- HTTP decision diagram: https://github.com/for-GET/http-decision-diagram (full docs: https://github.com/for-GET/http-decision-diagram/blob/master..., just the PNG: https://camo.githubusercontent.com/c26df6d372790e9f24d7e16d2...)

- Know your HTTP well: https://github.com/for-GET/know-your-http-well

[commandlinefan]

Whatever you say REST is, Roy T. Fielding will come around to tell you that it isn't that.

[recursivedoubts]

boooooo this man! booooooooooo!