Is it RESTful for a resource to have different values to different users?

Question

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?

Answer 1

Scenario 1

Yes, that is RESTful. There's a User resource, different clients can get different Representation of the object, nothing is wrong with that. What can make it not RESTful is how the request was made? E.g. do you use Authentication header or "session"?

Scenario 2

Not quite. Instead of returning some ACL permission object which interpretation specific to a client, you want to return hypertext links that allows client to manipulate the resource. This is easier to illustrate with a webpage that has an Edit link that takes the users to a page form they can fill and a Save button so they POST their changes.

Non-browser clients can do more than GET and POST requests, that's why the links are represented that way, i.e. href and method, so clients can do e.g. PUT requests.

The underscore prefixing _links is not RESTful, REST is an architectural style, not a set of rules that need to be followed. I believe links come from JSON-HAL and the underscore is to identify reserved properties.