I would be careful: if you're designing a REST API to be consumed by other developers and applications there are conventions and patterns you should stick to.
If your product or service doesn't exist without the UI then why bother with a REST API at all? Write a nice stateful application that is rendered server side. There are great frameworks for this in almost every language.
A good REST API is consumed by applications and developers and they expect you to stick to the conventions or they will turn to another provider if they can.
In REST, the API is the front-end. You can still do the front-to-back approach, mocking the data etc until you get the interface right. Then you work on how the application delivers data to the interface, which is the backend.
If you are designing a REST interface then I recommend a domain driven design approach. I've had a fair bit of success with that.
I also like to think in terms of denotational semantics which works rather well with REST APIs. The entities represent the domain objects which model what the system does. The state transfer operations become the game between the client and the system. If the domain maps cleanly the client and the server never have to guess or assume the state of the other. You can follow the operations from the URLs (HATEOS, etc).
What I find happens to some systems where the design is driven by the UI are domain models that span both the client and the server. This leads to routes that fill data for specific UIs, entities that have different representations based on which route they're fetched from, and the dreaded "RPC over HTTP," that the OP seems aware of.
A lot of this can be avoided if you never intend to expose your REST API to external developers. Just don't have one. Less to worry about.
Designing front-to-back that way makes a lot of sense. I just find that if you do that from a UI through a REST API that a lot of teams and developers skip on maintaining the REST conventions and then end up sad when their project becomes difficult to maintain and onboard new developers to.
If your product or service doesn't exist without the UI then why bother with a REST API at all? Write a nice stateful application that is rendered server side. There are great frameworks for this in almost every language.
A good REST API is consumed by applications and developers and they expect you to stick to the conventions or they will turn to another provider if they can.