RESTful services are independent from clients. That means that services can be consumed by different clients like applications, UIs, and so on.
In the case of UIs, you need to take into account permissions in order to only provide the actions the user is allowed to use. This prevents from having a button or a link displayed in the UI and when the user clicks on it, a forbidden message is displayed. Such issue is mandatory when an application uses a Web API / RESTful service and supports users with different roles like admin and read-only for example.
Using permission resources
Dedicated resources can be provided to return specific permission, permissions for a domain or all permissions. On their side the resources of the application must leverage these permissions to check if they can be executed or not in the context of a particular user.
A dedicated resource is provided to get the permissions, as described below:
GET /permissions [ contacts:access:read contacts:access:write contacts:access:delete companies:access:* (...) ]
Filtering must be also supported to get only a subset of permissions, as described below:
GET /permissions?categories=contacts [ contacts:access:read contacts:access:write contacts:access:delete (...) ]
We can notice that permissions arent directly linked to UI issues but are related to elements of the Web API and what we cant do on them.
Using such approach, were able to get a set of permissions using only one call.
Leveraging the OPTIONS method
OPTIONS method can be also used to determine communication requirements and the capabilities of the server without having to retrieve or perform an action on a resource. In conjonction with the header
Allow, this can allow to return back the permissions associated with the resource, i.e. which methods the current user is allowed to call.
This header contains a list of HTTP methods, in fact, the ones that can use, i.e. the existing ones and the ones youre authorized.
The following request can be done like that:
The corresponding response is described below. In this case, all methods can be used for the resource
HTTP/1.1 200 OK Allow: HEAD,GET,PUT,POST,DELETE,OPTIONS
Lets take now a concrete sample. We have two resources:
- One regarding a list of contacts – method
GETto get a list of contacts and method
POSTto add a contact
- One regarding a single contact – method
GETto get the contact, methid
PATCHto update (fully / partially) the contact and
DELETEto delete the contact
See this link for more details: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
If the current user has read-only permissions, he / she will have the following responses when using the method
OPTIONS for these two resources:
OPTIONS /contacts (...) Allow: GET,OPTIONS OPTIONS /contacts/contactid (...) Allow: GET,OPTIONS
The main drawback of this approach is that its per resource and you cant have all permissions for a specific domain in one call.