Comment by robertlagrant
6 hours ago
> That's the definition, I didn't made it up.
Your prior claim was that they only solve one problem, not about a definition. They solve several problems:
- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)
- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers
- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation
- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working
That second point is almost never true " the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"
In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.