Diferente contenido de recursos REST basado en privilegios de visualización de usuarios

Question

Deseo proporcionar diferentes respuestas a la misma pregunta para diferentes usuarios, en función de los derechos de acceso. He leído esta pregunta:

Excluding private data in RESTful response

Pero no estoy de acuerdo con la respuesta aceptada, que establece que se debe proporcionar tanto /people.xml y /unauthenticated/people.xml, ya que mi comprensión de REST es que un recurso particular, debe vivir en una ubicación particular, no varias dependiendo de la cantidad de información que le interese.

El sistema que estoy diseñando es incluso más complicado que ese. Supongamos que un usuario ha creado varios círculos de amigos y le ha asignado diferentes derechos de acceso. Por ejemplo, mi círculo de "conocidos" podría tener acceso a mi cumpleaños, y mi círculo "profesional" podría tener acceso a mi historial de empleo, pero no al revés. Para aplicar la respuesta de la pregunta que mencioné, necesito tener una forma de obtener todos los círculos del usuario (que es posible que desee mantener en secreto por razones de seguridad), y luego ir a través de /circles/a/users/42, /circles/b/users/42, /circles/c/users/42 y así sucesivamente y luego fusionar los resultados para mostrar la cantidad máxima de información disponible. Obviamente no hay necesariamente un solo círculo que obtenga toda la información que obtiene el resto de los círculos. Creo que esto es bastante complicado (tenga en cuenta que probablemente necesite hacer esto con varios tipos de objetos y que las versiones futuras requieran un procedimiento diferente), pero ¿qué sucede si quiero imponer restricciones de seguridad a un usuario en particular? el hecho que él también está en algunos de mis círculos? ¿Puede ese problema incluso ser resuelto? Incluso si me niego a responder a cualquiera de las consultas mencionadas anteriormente y creo una nueva que podría darme una respuesta, aún revelaría el hecho de que este usuario específico recibe un trato diferente debido a las restricciones de acceso individuales.

¿Qué me falta aquí? ¿Es posible para mí desarrollar un servicio web RESTful?

Si la conclusión es que el comportamiento no es RESTful, ¿esto todavía constituiría una situación en la que sería moralmente correcto romper el contrato de REST? Si es así, ¿cuáles son las implicaciones negativas? ¿Me arriesgo a problemas de caché de proxy, por ejemplo?

Answer 1

Acepto que la otra solución no parece correcta. Hace la estructura de URL complicada y más difícil de encontrar el recurso. Sin embargo, si realizó REST correctamente, no debería importar cuál es la URL del recurso ya que el servidor lo controla (y puede reubicarlo como lo considere oportuno). Si su cliente es realmente "REST", descubrirá los recursos que necesitaba a través de una negociación previa con el servidor. Entonces la ruta realmente no importaría en el cliente. No me gusta porque es confuso de usar, no debido a una violación de los principios de REST.

Pero eso probablemente no responda a su pregunta - Lo que no mencionó es su configuración de seguridad - presumiblemente usted está pasando un token de sesión con la solicitud como parte del encabezado de la solicitud. Por lo tanto, su procesamiento de back-end debe tener la capacidad de vincularlo a un conjunto particular de restricciones de seguridad. A partir de ahí, usted forma la lista con la lógica de negocios que necesita y devuelve un recurso limitado en función de la seguridad del usuario vinculada a la sesión.

Para el algoritmo en sí, uno generalmente implementa un algoritmo de tipo mínimo o más restrictivo que combina los datos permitidos en una respuesta (muy similar a los reinos de Java o al modelo de seguridad de usuario de Microsoft).

Si los datos están estructurados de forma diferente para el caso restringido/no restringido, puede crear dos representaciones diferentes de los datos y devolver los que el usuario haya autorizado ver. El cliente debería preguntar de todos modos los tipos de respuesta mime aceptados, y solo proporcionaría respuestas diferentes en función de la seguridad de la sesión en el encabezado de la solicitud. Alternativamente, podría proporcionar elementos opcionales con las representaciones y completar la base adecuada en la autorización (aunque esto es un poco hack-ee en mi opinión).

Answer 2

De acuerdo con la disertación de Fielding (que realmente es un gran escritura):

Un recurso es un mapeo conceptual de un conjunto de entidades, no la entidad que corresponde a la asignación en cualquier punto particular en el tiempo.

En otras palabras, si usted tiene un recurso que se define como "proyectos asignados del usuario que solicita" y las representaciones de los mismos accesible por un URI de /projects, no violan las restricciones de REST devolviendo una lista de proyectos (es decir, representación) para el usuario A y otra (representación) para el usuario B cuando obtienen ese mismo URI. De esta manera, la interfaz es uniforme/consistente.

Además de esto, RESTO sólo se prescribe que una instrucción de almacenamiento en caché explícita se incluye con la respuesta, ya sea 'caché para este largo' o 'no almacenar en caché en absoluto':

limitaciones de caché requieren que los datos dentro de una respuesta a una solicitud estén etiquetados implícita o explícitamente como cacheables o no almacenados en caché.

Cómo elige administrarlo depende de usted.

Teniendo esto en mente,

Debe sentirse cómodo devolver una representación de un recurso que varía en función del usuario que solicita una representación de un recurso en particular, siempre y cuando que no está violando las restricciones de una interfaz uniforme: no use un único identificador de recursos para devolver representaciones de diferentes recursos.

Si ayuda, considere que el servidor responde con representaciones variables de un recurso también - XML ​​o JSON, francés o inglés, etc. Las credenciales enviadas con la solicitud son solo otro factor que el servidor puede usar en determinando qué representación enviar en respuesta. Para eso está la sección del encabezado.