3 ms·

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

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 3y ago
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 3y ago
  If you define the terms exactly the way I want, then I win the argument! It's a very useful technique.
  - dimitrios1 3y ago
    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 3y ago
      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
recursivedoubts 3y ago
boooooo this man! booooooooooo!
commandlinefan 3y ago
Whatever you say REST is, Roy T. Fielding will come around to tell you that it isn't that.
troupo 3y ago
> 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 https://github.com/for-GET/http-decision-diagram (full docs: https://github.com/for-GET/http-decision-diagram/blob/master/doc/README.md https://github.com/for-GET/http-decision-diagram/blob/master..., just the PNG: https://camo.githubusercontent.com/c26df6d372790e9f24d7e16d2cfa16a142985109b237bbc0f482c47a717019fe/68747470733a2f2f7261776769746875622e636f6d2f666f722d4745542f687474702d6465636973696f6e2d6469616772616d2f6d61737465722f6874747064642e66736d2e706e67 https://camo.githubusercontent.com/c26df6d372790e9f24d7e16d2...) - Know your HTTP well: https://github.com/for-GET/know-your-http-well https://github.com/for-GET/know-your-http-well

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 3y ago

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 3y ago
If you define the terms exactly the way I want, then I win the argument! It's a very useful technique.
- dimitrios1 3y ago
  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 3y ago
    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

recursivedoubts 3y ago

boooooo this man! booooooooooo!

commandlinefan 3y ago

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

troupo 3y ago

> 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 https://github.com/for-GET/http-decision-diagram (full docs: https://github.com/for-GET/http-decision-diagram/blob/master/doc/README.md https://github.com/for-GET/http-decision-diagram/blob/master..., just the PNG: https://camo.githubusercontent.com/c26df6d372790e9f24d7e16d2cfa16a142985109b237bbc0f482c47a717019fe/68747470733a2f2f7261776769746875622e636f6d2f666f722d4745542f687474702d6465636973696f6e2d6469616772616d2f6d61737465722f6874747064642e66736d2e706e67 https://camo.githubusercontent.com/c26df6d372790e9f24d7e16d2...) - Know your HTTP well: https://github.com/for-GET/know-your-http-well https://github.com/for-GET/know-your-http-well