This is the dogma of CRUD, popularized by web frameworks. REST says nothing about granularity.<p>"a single endpoint relates to a single entity" is not a REST thing. I understand that for 99% the people they are the same thing, but they're actually not.<p>`GET /inbox` is not REST though, because it implies that the reply varies according to some authorization header. It messes up the "layered" idea of being able to cache stuff by their identification.<p>`GET /inbox/:account_set_id` is REST enough. `account_set_id` can be a `session_id`, it doesn't matter how you group things, as long as you identify each resource uniquely. It can be a huge resource, containing information about others inside, no problem.<p>You can even have multiple levels of granularity if you want:<p>`GET /inbox/:some_id` gets all inboxes<p>`GET /accounts/:acc_id/mailboxes/threads/by-date/latest/messages/by-author/first/cc/0` get the first cc'd email of the first author of the most recent thread<p>These two can live on the same application, RESTfully side by side. So can resources that fetch multiple stuff:<p>`GET /message-fields?list=subject,cc&fromAccounts=123,456&since=2023`<p>If you can name it, you can REST it. You can REST it even if you can't quite name it using `POST`.<p>`POST /graphql` is REST. It just isn't very CRUD-y, and by being a POST, it ignores a lot of the REST benefits (but doesn't necessarily contradict them).<p>TL;DR: CRUD frameworks appropriated the REST terminology and made a mess with its meaning.