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

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.