web-services - ejemplo - rest api example
Contenido de recursos REST diferente según los privilegios de visualización del usuario (2)
De acuerdo con la disertación de Fielding (realmente es un gran escrito):
Un recurso es una asignación conceptual a un conjunto de entidades, no la entidad que corresponde a la asignación en un momento determinado en el tiempo.
En otras palabras, si tiene un recurso que se define como "los proyectos asignados del usuario solicitante" y las representaciones de los mismos a las que se puede acceder mediante un URI de /projects , no viola ninguna restricción de REST al devolver una lista de proyectos (es decir, representación) para el usuario A y otra (representación) para el usuario B cuando obtienen el mismo URI. De esta manera, la interfaz es uniforme / consistente.
Además de esto, REST solo prescribe que se incluya una instrucción de almacenamiento en caché explícita con la respuesta, ya sea "caché durante todo este tiempo" o "no guardar caché":
Las restricciones de caché requieren que los datos dentro de una respuesta a una solicitud sean etiquetados implícita o explícitamente como cacheables o no cacheables.
Cómo eliges gestionar eso depende de ti.
Teniendo eso en cuenta,
Debería sentirse cómodo devolviendo una representación de un recurso que varía según el usuario que solicita una representación de un recurso en particular, siempre y cuando no esté violando las restricciones de una interfaz uniforme; no use un único identificador de recursos para devolver las representaciones de diferentes recursos.
Si le ayuda, considere que el servidor responde con diferentes representaciones 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 para determinar qué representación para enviar en respuesta. Para eso está la sección del encabezado.
Quiero proporcionar diferentes respuestas a la misma pregunta para diferentes usuarios, según los derechos de acceso. Leí esta pregunta:
Excluyendo datos privados en respuesta REST.
Pero no estoy de acuerdo con la respuesta aceptada, que establece que debe proporcionar tanto /people.xml como /unauthenticated/people.xml , ya que mi comprensión de REST es que un recurso en particular debe residir en un lugar en particular, no en varios. sobre cuánta de su información le interesa.
El sistema que estoy diseñando es incluso más complicado que ese. Digamos que un usuario ha creado una serie de círculos de amigos y les 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 de usuarios (que es posible que quiera 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 combine 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 cualquiera de los otros círculos. Creo que esto es lo suficientemente complicado (tenga en cuenta que probablemente deba hacer esto con varios tipos de objetos y que las futuras versiones podrían requerir un procedimiento diferente), pero ¿qué sucede si deseo imponer restricciones de seguridad a un usuario en particular a pesar del hecho de que él también en algunos de mis circulos? ¿Puede ese problema ser resuelto? Incluso si me niego a responder a cualquiera de las consultas mencionadas anteriormente y se me ocurre 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.
¿Que me estoy perdiendo aqui? ¿Es posible para mí desarrollar un servicio web RESTful?
Si la conclusión es que el comportamiento no es REST, ¿esto constituiría una situación en la que sería moralmente correcto romper el contrato REST? Si es así, ¿cuáles son las implicaciones negativas? ¿Me arriesgo a problemas de caché de proxy, por ejemplo?
Estoy de acuerdo en que la otra solución no parece correcta. Hace que la estructura de la URL sea complicada y más difícil de encontrar el recurso. Sin embargo, si RESTAURÓ correctamente, no debería importar cuál sea la URL del recurso, ya que el servidor lo controla (y es libre de reubicarlo como mejor le parezca). Si su cliente es realmente "REST", descubrirá los recursos que necesita a través de una negociación previa con el servidor. Así que el camino realmente no importaría en el cliente. No me gusta porque su uso es confuso, no por alguna violación de los principios REST.
Pero es probable que eso no responda a su pregunta. Lo que no mencionó es su configuración de seguridad, probablemente se trata de 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í, formará la lista con la lógica empresarial que necesite y devolverá un recurso limitado en función de la seguridad del usuario vinculada a la sesión.
Para el algoritmo en sí, por lo general se implementa un algoritmo de tipo menos o más restrictivo que combina los datos permitidos en una respuesta (muy similar a los dominios de Java o al modelo de seguridad del usuario de Microsoft).
Si los datos se estructuran de manera diferente para el caso restringido / no restringido, puede crear dos representaciones diferentes de los datos y devolver la que el usuario esté autorizado a ver. El cliente debería solicitar los tipos de respuesta mime aceptados de todos modos, y solo proporcionaría respuestas diferentes según 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 apropiada sobre la autorización (aunque, en mi opinión, esto es un poco hack-ee).