Two scenarios:
Scenario 1 - Redacting information on a resource
Let's say I've got a User
resource
id: string;
username: string;
address: string;
For privileged users they may see:
id: "1",
username: "bobby",
address: "123 Foo Lane"
However for less-privledged users, they see:
id: "1",
username: "bobby",
address: "<REDACTED>";
Is this RESTful or no?
Scenario 2 - Attaching user specific meta data to a resource
For example we have a Widget resource, which has raw data of the shape:
id: string;
name: string;
But the response also returns access permissions information to the response, for example an admin user might see:
{
data: {
id: "1",
name: "foo",
},
_accessControl {
canDelete: true,
canEdit: true
}
}
While and ordinary user sees:
{
data: {
id: "1",
name: "foo",
},
_accessControl {
canDelete: false,
canEdit: false
}
}
The reason we might want to do this, is to change frontend behaviour in regards to this resource (eg not showing a delete button if the user can't delete the resource).
Is this RESTfuL? How else might the server hint at the access permissions for the resource?
(FWIW - if using ACL based permissioning - you could have an acl
attribute on the resource, and client works out themselves whether they can edit the resource or not. However let's assume that's too costly for the the client to do).
This answer here appears to suggest something similar - is the convention of prefixing an attribute with an underscore to denote that 'this is user specific' an inherently RESTful concept?
Vary
header to prevent inappropriate caching.{"firstName": "John", "lastName":"Doe", "acl":[ $whatever]}