I'm not saying REST is the right approach to the apps you describe, but nothing you're describing is a REST issue per se. You're describing incompetent handling of network disconnects, cache invalidation and many more. Theses are issues that plague all distributed systems.
True, but we have generations of developers whose mental model for this stuff is based on stateless protocols, and that naturally bleeds through into the software architectures they produce. I definitely notice the difference when talking to engineers who have experience developing stateful software (e.g., desktop apps, client/server, etc.), vs. those whose experience is primarily with web apps (not that web apps can't be stateful, I guess just different levels).
I've been thinking about this a lot lately, in the context of offline-first mobile dev. That's a tough nut to crack, and I find myself re-evaluating some classic distributed system stuff I haven't really thought about in years. Gotta dust some old gears off!
I think you are reading something between the lines
I quoted from the article regarding the idea of using REST or similar ideas for 'everything'.
But my own text talked about statelessness used to worst effect, not REST.
The point was that there is a whole generation of developers who never wrote a desktop app.
A lot of them come from web. They treat the cloud as an extension of the device with no regard for the case where it can't be connected to at all (for some time) or the latency induced by the connection wrecks UX.
And I see one reason for that in the statement I quoted. But again, what I wrote myself was not saying anything about REST.
