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
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.
1
6
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
You said something, I disagreed, then I think @clemensv agreed with me, then you with him :) Confusion …
1
What Clemens pointed out here is that in most use cases of “REST” clients and servers are communicating in very coupled patterns over a super generic architectural style. This is nothing like how a browser works or what REST is designed to solve
Think about that for a few mins.
1
What we agree on is that most HTTP API clients and servers are way more coupled than REST suggests. Our disagreement is whether that’s a good thing. I contend that it’s a missed opportunity, because in most scenarios, it would add a lot of value. You seem to think differently.
May 4, 2019 · 6:21 PM UTC
1
2
