I'm building an app with a mobile client first and an administrative web dashboard later. I have a listings resource, but different callers need different views and DTOs:
1. Listings available to the current user, returned as PublicListingDto[].
2. Listings belonging to a specified user, also returned as PublicListingDto[].
3. The currently authenticated user's own listings, returned as OwnerListingDto[].
4. A paginated listing view for administrators, returned as ListingDto[].
I'm considering routes such as /listings, /listings?sellerId=123, /me/listings, and /admin/listings. I'm unsure whether separate /me and /admin resources are appropriate in REST, or whether one /listings endpoint should vary its results based on the authenticated user's role. I also want to avoid requiring the client to repeatedly provide its own user ID when requesting personal data. What endpoint structure and authorization approach would be clean and maintainable as the application grows?
3 Answers
I’d start with /listings for public listings, /listings?sellerId=123 for viewing a particular seller’s public listings, and /me/listings for the authenticated owner view. An administrator could use /admin/listings if that endpoint has a distinct DTO and broader permissions. The important part is keeping the response contract and authorization rules explicit; route aesthetics matter less than making the behavior unsurprising and easy to extend.
A single /listings endpoint can work well. Use query parameters for supported filters such as sellerId and pagination, then apply authorization and security trimming on the server. Never rely on the client-provided sellerId to decide what the caller is allowed to see. The server should derive the authenticated user from the token and enforce the relevant rules.
There is no universal REST rule that requires one particular URL layout. /me/listings is perfectly reasonable when the identity comes from authentication rather than from a path parameter, and it makes the client API clearer. Likewise, an admin-only route can be useful if the response shape, filtering, pagination, or authorization behavior is substantially different. Keep the route if it represents a genuinely different use case, not just because the name looks more RESTful.
The user ID in a JWT is normally represented by the subject claim, often called sub. That identifies the caller, but it should not be confused with trusting a sellerId supplied in a request. Authorization still has to be checked on the server.