how - python rest api example

¿Qué significa realmente el principio de apatridia de REST?

Question

Después de leer los artículos introductorios sobre REST ( tesis de Fielding y otros), mi percepción de la apatridia es que no debería haber objetos de sesión en el lado del servidor. Sin embargo, veo que Flask (y quizás otros marcos de REST en diferentes tecnologías que no conozco) nos da un objeto de sesión para almacenar información en el servidor en este example :

@app.route(''/login'', methods=[''GET'', ''POST''])
def login():
  if request.method == ''POST'':
    session[''username''] = request.form[''username'']
    return redirect(url_for(''index''))
...

Seguramente, estoy entendiendo mal la apatridia de REST. ¿Entonces, qué es en realidad?

Answer 1

En la arquitectura REST, el estado de la sesión se mantiene completamente en el cliente. Esto significa que los datos no se pueden dejar en el servidor en un contexto compartido y todavía tenemos que enviar los datos repetitivos (sobrecarga por interacción) en una serie de solicitudes. Al mantener el estado de la aplicación en el lado del cliente, esto reduce el control del servidor sobre el comportamiento consistente de la aplicación, ya que la aplicación se vuelve dependiente de la implementación correcta de la semántica en varias versiones de clientes. Sin embargo, esta restricción induce las propiedades de visibilidad, confiabilidad y escalabilidad.

• La visibilidad se mejora porque un sistema de monitoreo no tiene que mirar más allá de un solo dato de solicitud para determinar la naturaleza completa de la solicitud.
• La confiabilidad se mejora porque facilita la tarea de recuperación de fallas parciales.
• La escalabilidad se ha mejorado porque no tener que almacenar el estado entre las solicitudes permite que el componente del servidor libere recursos rápidamente, y simplifica aún más la implementación porque el servidor no tiene que administrar el uso de recursos entre las solicitudes.

vea http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Answer 2

Los propósitos de introducir la restricción de apatridia en REST incluyen mejoras a la visibilidad, confiabilidad y escalabilidad. Esto significa que los proxies y otros intermediarios pueden participar mejor en los patrones de comunicación que involucran mensajes sin estado auto-descriptivos, la muerte del servidor y la conmutación por error no producen problemas de sincronización del estado de la sesión, y es fácil agregar nuevos servidores para manejar la carga del cliente nuevamente sin Necesidad de sincronizar el estado de la sesión.

REST logra la apatridia a través de una serie de mecanismos:

1. Al diseñar métodos y patrones de comunicación que no requieren que el estado se mantenga en el lado del servidor después de la solicitud.
2. Al diseñar servicios que exponen las capacidades para muestrear directamente y hacer la transición del estado del servidor sin dejar el estado de la aplicación
3. "Aplazando" o devolviendo el estado al cliente como un mensaje al final de cada solicitud siempre que se requiera el estado de la sesión o el estado de la aplicación

La desventaja de la apatridia se expone en ese último punto: las aplicaciones que demandan algún tipo de estado de sesión persisten más allá de la duración de una sola solicitud, deben enviar ese estado al cliente como parte del mensaje de respuesta. La próxima vez que el cliente desee emitir una solicitud, el estado se transfiere nuevamente al servicio y luego se devuelve al cliente.

Puede obtener más información aquí http://soundadvice.id.au/blog/2009/06/

Answer 3

No, lo entiendes bien. No debe haber ninguna "sesión" en un servicio REST. Siempre verifique que pueda enviar cualquier URI por correo, manténgalo en los marcadores y hágalo referencia en los enlaces. De hecho, esta es la razón por la cual REST es tan importante para la Web: no hay recursos REST completos = no hay más enlaces. La autenticación solo debe realizarse al acceder a la representación del recurso.

Lo que puede tener en lugar de sesiones es un objeto de usuario (por ejemplo, un carrito de compras) que puede modificarse mediante métodos REST. Esto es diferente de una sesión, ya que, por ejemplo, podría haber servicios donde podría autorizar a otras personas a ver su carrito de compras.