This is the dogma of CRUD, popularized by web frameworks. REST says nothing about granularity.
"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.
`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.
`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.
You can even have multiple levels of granularity if you want:
`GET /inbox/:some_id` gets all inboxes
`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
These two can live on the same application, RESTfully side by side. So can resources that fetch multiple stuff:
If you can name it, you can REST it. You can REST it even if you can't quite name it using `POST`.
`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).
TL;DR: CRUD frameworks appropriated the REST terminology and made a mess with its meaning.
"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.
`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.
`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.
You can even have multiple levels of granularity if you want:
`GET /inbox/:some_id` gets all inboxes
`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
These two can live on the same application, RESTfully side by side. So can resources that fetch multiple stuff:
`GET /message-fields?list=subject,cc&fromAccounts=123,456&since=2023`
If you can name it, you can REST it. You can REST it even if you can't quite name it using `POST`.
`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).
TL;DR: CRUD frameworks appropriated the REST terminology and made a mess with its meaning.