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!
Your reply neatly describes the 'why' of the issue I described.
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.
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.
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.
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)