If you all need to do is basic persistence and don't want to bother with setting up your own backend, look into services such as https://restdb.io/ or https://fauna.com/ - be careful about security if you are embedding this in your front-end app.

Otherwise, writing your own backend using RPC-named express routes is more than sufficient. The reason why REST became common is that RPC routes can become messy.

Another poster gave the example of "SaveWidget" as an RPC endpoint. This can cause problems for some teams that have no conventions and they end up with "SaveFoo" and "BarSave" endpoints. REST solves this somewhat by relying on HTTP verbs so both endpoints are normalised to "POST /foo" and "POST /bar".

Finally, if your web app is truely simple with only a couple of backend endpoints needed, then whatever you choose is generally fine. Structural and architectural patterns exist to provide a framework around managing complexity.

If your app is not complex, most people - and it's important to consider this includes your future self that has forgotten your implementation details - can grok the codebase without too much trouble. If anything, as your question suggest, over-engineering a simple app can lead to greater confusion.