We have a REST api endpoints that return collections of objects where users could perform different types of actions on those objects. We need it to turn on/off different UI options based on that access info.
We are thinking about packing them as metadata into each response object but I can see that become inefficient at some point in time.
Is there some other way of implementing this? Other approach? Or is that more/less usual approach?
Of course the most natural approach is to list the possible actions for each item. In fact, a literal interpretation of the REST approach (which I don't necessarily subscribe to) would suggest to do exactly this. That way, the client does not need to understand anything about the rules when or when not to allow some actions.
However, this easily gets you into difficult terrain, and it might be reasonable to implement alternatives.
The simplest (but not the worst) alternative would be to show all possible actions in the list, and communicate to the user when they're trying to use one that isn't allowed to their role, that isn't possible due to some complex state of the item, etc. Of course you risk that users get frustrated about clicking on something and getting a negative response, but on the other hand they could get a detailed explanation which hopefully helps them to understand why they could not perform that action.
Another option would be to query the action enablement after the list has been received, updating the UI accordingly. Updating UIs after a quick initial rendering isn't unusual, and depending on the way the actions are presented to the user it might be very unobtrusive (for example, when the list of actions is available by clicking on a menu button). But this causes additional endpoint queries, which you likely want to avoid.
You can also mix and match options, of course. The initial list might include an indication of which actions are generally possible based on the user's role (for example, a user who does not have permission to delete items might not be shown the dustbin icon at all), and more complex permissions may be evaluated either in a delayed fashion or when the user actually tries to execute the action.
Which one is best for your application is up to you to decide. Since this is more an implementation detail than a general architectural decision, you may just as well implement what is easiest and reasonable now, and reserve the right to change it later when it turns out that the initial decision wasn't the best.
I agree that the approach you described is not efficient in the long run.
The usual approach is to implement role-based access control (RBAC) on the server side. This involves assigning roles to users and granting permissions to those roles. Then, on the client side, you can query the user's role and determine which UI options to display based on their permissions.
