Stop using REST for state synchronization
tl;dr: Most apps need state synchronization, not state transfer. We should replace REST and friends with proper state synchronization protocols where appropriate.
Apart from getting into van life in Europe and working on the Eqlog Datalog engine, I’ve also spent some time of my sabbatical building various webapps. The tech stack I used was React + Typescript for the frontend and a REST server implemented with Rust and the Axum library as backend. Rust might be somewhat unusual, but I think otherwise this is a very typical setup.
What struck me is how incredibly cumbersome, repetitive and brittle this programming model is, and I think much of this is due to using REST as interface between the client and the server. REST is a state transfer protocol, but we usually want to synchronize a piece of state between the client and the server. This mismatch means that we usually implement ad-hoc state synchronization on top of REST, and it turns out that this is not entirely trivial and actually incredibly cumbersome to get right.
It’s probably easiest to explain what I mean with an example that’s part of most webapps in some variant: An input element that allows the user to edit a piece of text that is saved to the backend database. Using REST we can model this as a path, say /api/foo, that supports GET and POST methods to fetch or replace the text by a given value (perhaps also DELETE and PUT if you want to complicate things). A React component that allows users to edit this piece of text will probably display a text input element, GET the initial value when the component is created and POST a new value when the text input loses focus. We show an error message with a retry button if a request failed, and we display a spinner while requests are in-flight. Here’s what it might look like:
