in this case there is no reason to do that and you lose all possibilities of using cache if that is desirable
GET /users/@me/accounts/:id --> specific user account
GET /users/@me/accounts --> all user accounts
would suffice and would read naturally , it would also give you ability for other user with appropriate credentials (admin kind) to see some other user account information
yes, very disappointed with design decisions (I understand that from a purist perspective URI is opaque but well named URIs help communication with people)
My point is that in complex systems 'get' use cases come up that don't fit well in urls.
Suppose you have too many accounts to list, so you start taking predicates in the API, or you start returning a pagination token that's passed back in on a subsequent requests. You quickly overwhelm URIs and have to start serializing complex objects in headers or query params. Eventually you give up and switch to POST so you can just post a json body and be done with it.
I do build a complex systems and pagination payload always have links to prev/next etc. , POST for GET would kill all client side and server side caching we leverage and would make system really hard to scale. We still didn't run into compelling case to use POST for this type of fixed queries.
What you are talking is ad hoc search capability and that is usually done differently either by posting content type which indicates search payload or using different generic URI for search queries within a whole system
GET /users/@me/accounts/:id --> specific user account GET /users/@me/accounts --> all user accounts
would suffice and would read naturally , it would also give you ability for other user with appropriate credentials (admin kind) to see some other user account information yes, very disappointed with design decisions (I understand that from a purist perspective URI is opaque but well named URIs help communication with people)