I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with t

I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with their UIs architected into broadly similar views, I basically just go for an additive model of providing a default RESTful API but then additional view-specific, and then if necessary even client-specific, endpoints on top where this makes sense. Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging. For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.