the MVC framework folks more or less ruined REST, focusing entirely on HTTP methods to mimic SQL DML, and URLs to represent entities
6
7
4
36
I mean. REST wasn’t suitable for HTTP API’s in 99% of use cases. People were told to use “REST”.
2
1
10
I don't get it. REST was invented by one of the principal HTTP spec authors. For these use cases HTTP was suitable but REST was not? For me REST means HTTP done right, so that doesn't add up in my mind
1
1
Sure but not every app protocol needs REST, very few actually. It’s like 2% for us. But quite a few use some of the constraints.
2
2
HTTP is the protocol. REST is an architectural style designed to deliver CONTENT to platform agnostic client implementations in a very very generic way. This architectural style has VERY little in common with application API’s in general. This is why it was misused.
2
1
10
Replying to @kellabyte @jbogard @piether
The content statement is only true if your web pages never include forms. REST is an architectural style that allows the server to provide the client with interaction options dynamically. Admittedly unnecessary if your want your clients and server to be more tightly coupled.

May 4, 2019 · 5:42 AM UTC

1
6
Replying to @stilkov @kellabyte @jbogard @piether
I thought we’re kinda done with litigating that, but ... 😁 If you have a client and the client does a thing and then does a subsequent, dependent thing, and the client is hardwired to who to talk to for the subsequent dependent thing, the interaction isn’t REST.
2
4
8