How should REST endpoints handle current-user and admin views of listings?

0
3
Asked By MellowQuokka42 On

I'm building an app with a mobile client now and an admin dashboard planned for later. I have a listings resource, but different use cases return different DTOs:

1. Listings available to the current user: PublicListingDto[]
2. Listings belonging to a specified user: PublicListingDto[]
3. My own listings: OwnerListingDto[]
4. All listings for an admin dashboard, with pagination: ListingDto[]

I'm considering routes such as /listings, /listings?sellerId=123, /me/listings, and /admin/listings. For the current-user case, I'd prefer not to make the frontend provide its own user ID, since that value already comes from the authenticated token. Is it reasonable to create separate /me and /admin resources, or should everything use one /listings endpoint with query parameters and authorization determining the result?

3 Answers

Answered By OrbitLime23 On

There is no universal REST rule that requires one particular URL shape. /me/listings and /admin/listings are perfectly reasonable if they make the API easier to understand. The important part is that the routes are predictable and that authorization is enforced independently of the path. Also, the sub claim in a JWT commonly identifies the authenticated user; it should be used by the server rather than copied into requests when it represents the caller.

Answered By MapleRook81 On

I’d start with /listings for public or generally available listings, /listings?sellerId=... for viewing a particular seller when permitted, and /me/listings for the authenticated owner view. An admin-only listing query can remain /listings with an admin authorization policy, or use /admin/listings if the response and behavior are substantially different. Separate DTOs are fine, but avoid making route names carry all the business logic; let the authorization and representation rules determine what each caller receives.

Answered By CedarFox7 On

A single /listings endpoint can work well. Use query parameters such as sellerId, page, and limit for filtering and pagination, then apply authorization and security trimming on the server. Never trust a sellerId supplied by the client to decide what the caller is allowed to see. If the caller is requesting their own listings, the server can derive the user ID from the authenticated token.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.