And this also is exactly the downside of this approach. Instead of layering abstractions (where you API is just there to provide data access and nothing more) you are now creating a "feature silo' throughout your entire tech stack. Which is fine for small things, but for big applications you will end up with thousands of endpoints, API wrappers, queries etc. The idea of REST wasn't really to be uniform, but to abstract the access to data and make its feature independent. So then all the features that have anything to do with channels or messages would use the same dozen or so endpoints. That is why it was quite popular: no more SOAP like action-per-feature madness, but a standard and reusable way of accessing any model.

The downside to this is indeed API chattiness, but there are way better ways to solve this. For example, graph data access layers allow clients to exactly specify what data they want to retrieve or update without the backend having any knowledge about the feature it is used for. Then you keep the power of abstracting, but aren't as limited as your are with plain REST. Another major downside to REST is the lack of structural metadata, something both SOAP and most graph access layers have.