I have a entity Store which is queryable via a REST endpoint /api/v1/stores. Users can only access stores that they have permission to access. Users can be an admin which have a right to configure the store settings, or they can be a manager who can manage the stores orders. A user could also be both.
From a UI perspective my app has two views, an admin view and a management view. In either of these views I want to retrieve the stores that only have the relevant permission for that view (ie, the admin section only shows stores I have admin rights on, and the management view only shows stores I have management rights on).
If I was just to fetch stores from the /api/v1/stores endpoint with no explicit filter, this would return all stores I have access to in any fashion (ie, both admin and manager access).
The question then is what is the best practice here for filtering the stores to only return the ones I'm interested in?
Should it be a query filter such as /api/v1/stores?filter=permission:admin? Should it be a role specific endpoint (I don't particularly like this idea)? Or is there something better?
I can obviously implement whatever I want here, but I was wondering if there is any standard approach for filtering results by UI defined permission level.
Summary
I'd suggest something like:
/api/v1/users/{userId}/stores/admin/api/v1/users/{userId}/stores/management(you could even replace
{userId}withme- see later).My thoughts as to why
Filter isn't needed, in my opinion. It would only be useful if you're going to have extensible types of filter parameter (i.e. lots of them, and dynamic) or if you needed to apply filters in combination.
You mention that there are two different views in the UI, which says to me they're a well defined case. So worthy of their own endpoints. You'll never (presumably) need to access both Admin and Management stores in the same call, because they're in different UI views.
I've taken a user-centric view of the endpoint structure, so it's clear that the stores are only the ones relevant to that user. That's why I've put a user stem in front of it.
Dropping {userId}
Assuming you have proper authentication on the endpoints, you'll already know the User ID.
If there's no requirement for your user to access a different user's data, then you could simplify the endpoints like this:
/api/v1/users/me/stores/api/v1/users/me/stores/admin/api/v1/users/me/stores/management...this retains the option for you to add a {userId} path later.