I disagree. The idea with REST is to push state to the backend, and add links to substates, so that the protocol doesn't have to be stateful, and logic is pushed to the edges of the network.
SPAs breaks this principle by making webpages into fully fledged apps who do their own state tracking and navigation. This was never the intention of REST. The idea was to make the webpages themselves linkable RESTful substates of the application, and having the browser do the rest.
From the SPA angle, RPC might look like a good solution. But RPC in itself doesn't solve any problems except literal remoting.
A RESTful API makes states linkable and removes ordering dependences from the API.
Look at web frameworks which tried to make web sessions stateful. They are dealing with all the pains that REST solves.
Not true. People are trying to use the mental model of a huge stateful desktop app and apply it to the web. That's not to say it's a good idea to use that model, far from it.
The web was designed to avoid it for multiple very good reasons. In fact, the success of the web has partially been attributed to those very design decisions, so it might make sense to pay attention to them.
SPAs breaks this principle by making webpages into fully fledged apps who do their own state tracking and navigation. This was never the intention of REST. The idea was to make the webpages themselves linkable RESTful substates of the application, and having the browser do the rest.
From the SPA angle, RPC might look like a good solution. But RPC in itself doesn't solve any problems except literal remoting.
A RESTful API makes states linkable and removes ordering dependences from the API.
Look at web frameworks which tried to make web sessions stateful. They are dealing with all the pains that REST solves.