ventajas - La apatridia de una API REST con usuarios autenticados

ventajas de hateoas

Question

Actualmente estoy diseñando un APT REST Http. (Con HATEOAS, hacer que los clientes sean más "simples" y evitar que los clientes hagan cosas complicadas, en lugar de dejar que la API les diga qué hacer ...)

Debido a la característica social de la aplicación, para interactuar con la aplicación, los usuarios deben estar autenticados, y cada usuario tendrá una "vista" ligeramente diferente de los datos. Tomaremos Twitter como ejemplo, será más fácil para todos.

Para autenticar a los usuarios, usaremos OAuth, fácil.

Por lo tanto, en el cliente (aplicación ios ...), un usuario aleatorio podría ver una lista de usuarios que debería ver:

Adrien: Following
John: Not Following
Rambo: Not Following

Y tal vez otro usuario vea:

Adrien: Following
John: Not Following
Rambo: Following

Para lograr esto, la primera solución sería para el cliente (en conjunto, la aplicación iphone / web / etc), para obtener una lista de todos los usuarios que sigue el usuario autenticado y cada vez que el cliente muestra una lista, compare cada uno de ellos. usuario con la lista de usuarios seguidos para saber si debe mostrar "No siguiendo" o "Siguiente".

Las solicitudes / respuestas serían:

GET /users
Authorization: OAuth token...
[
{"id": 1, "name": "Adrien"},
{"id": 2, "name": "John"},
{"id": 3, "name": "Rambo"}
]

y

GET /users/{myid}/following
Authorization: OAuth token...
[1, 3, 25, 1210, 9]

Esto parece ser bastante, sin estado. Bueno.

Ahora, ¿qué sucede si deseo hacer que la vida de los desarrolladores de clientes sea más fácil e incrustar directamente en la respuesta de la lista de usuarios, la relación de cada usuario, en relación con el usuario autenticado?

GET /users
Authorization: OAuth token...
[
{"id": 1, "name": "Adrien", "relationship": "Following"},
{"id": 2, "name": "John", "relationship": "Not Following"},
{"id": 3, "name": "Rambo", "relationship": "Following"}
]

Entonces, preguntas:

• Parece romper la cosa "sin estado", ¿realmente rompe la restricción sin estado REST ?
• A continuación, ¿crees que es una buena o mala práctica para una API hacer esto?

Answer 1

De Roy Fieldings Architectural Styles y el diseño de arquitecturas de software basadas en red :

3.4.3 Client-Stateless-Server (CSS)
The client-stateless-server style derives from client-server with the additional
constraint that no session state is allowed on the server component.
Each request from client to server must contain all of the information necessary
to understand the request, and cannot take advantage of any stored context on
the server. Session state is kept entirely on the client.

Enlace: dissertation

Por lo tanto, la incorporación de datos de entidad directamente en la respuesta no hace que su solución sea sin estado.

En buenas prácticas:

Es mucho mejor servir realmente los datos del usuario que una lista de números para que el cliente descubra qué hacer con ellos.

Sin embargo, dependiendo de la cantidad de datos para cada usuario, puede considerar dar una lista de enlaces al recurso del usuario y establecer también la relación de "seguimiento". Luego, el cliente puede obtener los detalles de los usuarios necesarios. La solución que elija dependerá de lo que crea que el cliente necesitará, puede terminar utilizando varios enfoques.

Answer 2

Definitivamente, debe insertar la relación en la respuesta de la lista de usuarios. Sería una mala práctica forzar a los clientes a calcularlo.

Esto no rompe el límite sin estado de REST, ya que son las interacciones las que no tienen estado, no los sistemas. El servidor casi siempre tendrá que almacenar y mantener el estado. Por ejemplo, el servidor deberá mantener el estado de quién está siguiendo a quién.

Finalmente, creo que no está obteniendo completamente la parte "Estado" de Hipermedia como el motor del estado de la aplicación. Básicamente, los recursos son máquinas de estado. Cuando GET un recurso, las transiciones de estado válidas que se presentan tienen controles de hipermedia (enlaces y formularios) en la respuesta. Al seguir estos enlaces y enviar los formularios, el cliente puede cambiar el estado de estos recursos.

Answer 3

Incluir la descripción del tipo de relación en el cuerpo de la respuesta no está rompiendo la restricción sin estado. La restricción sin estado significa que el servidor web puede responder a la solicitud sin depender de ninguna solicitud previa (como lo han mencionado Tom , Jacob y kgb ).

No estoy calificado para decir si lo que está haciendo es una "mejor práctica" o no, pero en general Roy dio las siguientes razones a favor y en contra de hacer que su API sea apátrida (consulte la sección 5.1.3 de su dissertation ). Como muchas cosas en la vida hay una compensación:

Problemas con un sistema sin estado

• Las solicitudes pueden tener que ser más grandes. Dado que los datos no se almacenan en el servidor entre solicitudes, es posible que cada solicitud deba incluir las mismas cosas una y otra vez.

• En un sistema sin estado, el servidor depende de que el cliente mantenga el estado correctamente.

Beneficios de un sistema sin estado

• Usted sabe lo que una solicitud está tratando de lograr basándose únicamente en su contenido.

• Confiabilidad, ya que "facilita la tarea de recuperación de fallas parciales". Ver la referencia 133 citada en la dissertation para más información.

• Escalabilidad mejorada. Administrar el estado entre solicitudes, particularmente en un entorno distribuido puede ser bastante complejo. Lo primero que viene a la mente aquí es el estado de la sesión InProc de ASP.NET , está bien para un servidor único, una instancia de proceso única, pero no se escala muy bien.

Recursos REST

Además, de acuerdo con la definición de Roy de un recurso, no estaría de acuerdo con cómo creo que está definiendo sus recursos, ya que cada usuario obtiene una "vista" ligeramente diferente de los datos . Roy define un recurso como una función de membresía que varía con el tiempo (consulte la sección 5.2.1.1 en la dissertation ). El recurso de la lista de usuarios que ha definido anteriormente varía según el tiempo y el encabezado de autorización. Dos clientes diferentes que solicitan / usuarios al mismo tiempo probablemente terminarán con resultados completamente diferentes. Esto hará que el caché de los resultados sea más difícil.

EDITAR: el uso del encabezado HTTP HTTP permitiría su almacenamiento en caché.

Answer 4

No veo la correlación entre incrustar la información de "relación" en el recurso /users y la restricción sin estado. Así que no veo ningún problema.

Sin embargo, yo diría que usted está rompiendo la restricción de "identificación de recursos".

/Users para usted y /Users para mí mostrarán un conjunto de relaciones completamente diferente. Yo diría que esos son dos recursos diferentes y, por lo tanto, deberían tener URI distintos.

Hay algunos escenarios en los que puede cambiar una representación en función de quién es el usuario (por razones de seguridad, por ejemplo), pero este caso es demasiado para mi gusto.

Answer 5

Si cree que agregar la propiedad "relación" a los usuarios que rompen la restricción sin estado, entonces agregarla cuando "/ following" esté en la solicitud, también lo estará.

Yo diría que "sin estado" significa que ninguna respuesta depende de las otras solicitudes / respuestas.

HTTP es un protocolo stateless , pero puede almacenar una gran cantidad de datos sobre el usuario en los encabezados de solicitud / respuesta (y no estoy hablando de sesiones / cookies)