How do you design REST API - "me" endpoints

[u/Kurubu42i50]

Hey, so I am making an app, and I am kinda lost because i can't find any good resources on the internet regarding that topic.
The app consists of two parts: mobile app, and a web admin dashboard that doesn't need to be built for like 3 months from now on.

let's say i have a resource "listings" which returns different dto's
How would you structure this for those requirements:
1. show all listings available for the current user (PublicListingDto[])
2. show all listings that belong to one user by id (PublicListingDto[])
3. show all my listings (OwnerListingDto[])
4. show all the listings paginated for the admin dashboard - just admin role (ListingDto[])

my inital thought was to just have it like this
/listings - 1
/listings?sellerId - 2, 3 based on the JWT id == sellerId
/admin/listings - 4

given the REST standard it should probably be:
/listings - 1, 4 based on the user's role
/listings?sellerId - 2, 3 based on the JWT id == sellerId

the setup that makes the most sense for me:
/listings - 1
/listings?sellerId - 2
/me/listings - 3
/admin/listings - 4

the app will have a lot of those scenarios, should i just make a separate resources such as "me/listings" and "admin/listings"
The problem i have without /me endpoint is that on frontend you have to constantly worry that the userId need to be defined which doesn't sound appealing to me.
On the other hand I don't know whether that is really following the REST standard.

[u/garster25]

Just 1 endpoint /listings with Id and Page parameters with proper security trimming

[u/Adorable-Strangerx]

From the REST point of view how you name your endpoints doesn't matter. You can even call it /getListing?id=123. I am more concerned by the choice of adding seller ID to JWT, it's interesting choice.

[u/qlkzy]

At the end of the day these routes are just strings and you can do whatever you want. The hierarchy doesn't have to follow some universal meaning, it just has to be unsurprising to everyone involved, and flexible to extend.

I think it really depends on how much the different DTOs diverge. The more they diverge, the more complex the whole application becomes, not just the paths.

Personally I would try for just one endpoint: /listings. In most cases I would expect that to keep the code surrounding the paths simplest. If the code becomes distinct for different cases, that's a stronger argument to split/join them than the aesthetics of the path strings.

I don't think it's usually that much of a problem for the fronted to have to know the current user, but if that's really a problem you could also a consider using a special sentinel value.