5 ms·
> This is the deep, deep irony of REST’s ubiquity today. REST gets blindly used for all sorts of networked applications now [...] This. I don't even know where
by virtualritz 5y ago
> This is the deep, deep irony of REST’s ubiquity today. REST gets blindly used for all sorts of networked applications now [...]
This. I don't even know where to start if I were to talk about the idiocy behind stateless networked apps on my phone.
My fav. example are car/scooter sharing apps. Some even 'forget' the map tiles between screen locks.
But pretty much all of them 'forget' your active booking.
And the route to the vehicle.
Which is just great when you are walking from a party (where you had the host's WiFi to do the booking) in a neighborhood with shitty mobile network, in Winter.
For something like ShareNow it can take up to three minutes on an 'E' connection to load missing map data, active booking and route to car.
If your phone locks screen during that time ... just unlock and ... wait another three minutes.
You may have guessed that I'm talking first hand experience here. Frequently so, ofc. I'm using these apps heavily here in Berlin, since 2014.
It's the reason I bought gloves that let you use a touchscreen. Not kidding.
Even though it's valid for 20 minutes and the likeliness of the the vehicle becoming unavailable due to reasons outside of the user canceling the booking or changing the phone's system time are pretty much non-existent even this info is not retained on the Phone. Because that would entail state.
The idea that the network interface of an app can be RESTful yet the app itself can carry state and cache stuff on the phone – and that is A-OK – seems absent from the minds of whoever develops this.
EDIT: typo(s)
- twic 5y agoThese apps are poorly written, but this has nothing to do with REST, or HTTP being stateless. Indeed, HTTP being stateless forces apps to implement state management which can naturally survive network interruptions. If the apps you are complaining about used a stateful protocol, they would be even worse!
- virtualritz 5y agoMaybe you misread me. I said the the protocol can be stateless but the app itself, towards the user, should carry state – where this makes sense. E.g. in the cases I described.
- alangibson 5y agoI'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.
- fulekia 5y agoTrue, 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!
- virtualritz 5y agoCould have saved me relying to parent but saw this after. Your reply neatly describes the 'why' of the issue I described.
- virtualritz 5y agoI 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.
- ebiester 5y agoI worked on one of these. We had giant problems with caching. You have an assumption that the likeliness of the vehicle becoming unavailable but there are so many ways this isn't true. The edge cases of car sharing can be downright weird. (For example, some services have both app and mobile, and can cancel via a call to customer service. Let's say that a user books on mobile and cancels by app or even by calling to customer service. They are refunded the money. What happens when they then try to unlock the car? What happens if the signal to the car is poor?) The tension between good UX and bad actors is amplified by $20,000 dollar assets and had some of the most difficult problems I've worked in from a requirements standpoint. The easiest thing was to avoid caching where possible.
- bombela 5y agoUltimately it appears the problem you and the parent post shared on both side of the system is bloat. Too many bytes to transfer for every update.