Should a RESTful representation depend on user permissions?

Question

I don't think it is RESTful when authorization infiltrates into the representations of resources. The identity of the current user is strictly client state, so it should not effect on the representation of a resource except if identification factors or user id or permission details is sent with the request.

If you were using sessions this would be the stateful part of the process: For example if you want to read the profile page of somebody, you will have 2 representations: users/123 and users/123?editable=true. It depends on the permissions of the session whether you can choose the editable one. Where should the editable link appear? If it appears in the /users/123 representation only in that case if you have the permissions, then it violates the statelessness constraint of the service, because the representation of the resource will depend on the permissions of the current session. :S So if you want to have different representation for each user then you have to send something about this with every request.

Does anybody have a good solution for that? Is it possible to use sessions and separate the stateful part from the service?

Is it possible to completely separate the permissions dependent part from the resource dependent part by creating the response? (In that case the resource dependent part would be well maintainable even with sessions and it would be much easier to cache it.)

Answer 1

Should a RESTful representation depend on user permissions?

Yes.

I don't think it is RESTful when authorization infiltrates into the representations of resources. The identity of the current user is strictly client state, so it should not effect on the representation of a resource except if identification factors or user id or permission details is sent with the request.

It is client state, but you can send it with every message, so it does not violate the stateless constraint.

Is it possible to use sessions and separate the stateful part from the service?

Server side sessions are not allowed because they would violate the stateless constraint.