forms - practices - ¿Por qué la autenticación basada en formularios NO se considera REST?
rest authentication (4)
Aunque "pienso" lo entiendo necesito algo de claridad. Con la autenticación PURE Restful, las cosas se vuelven un poco difíciles de manejar y el uso de formularios ayuda mucho con la interfaz de usuario de la aplicación (es decir, tener una página de inicio de sesión separada, ¿olvidó los enlaces de contraseña, el cierre de sesión más fácil? Etc.)
Ahora vienen las formas y algunas personas dicen "no descansan", ¿qué es "no descansan" sobre ellas? ¿Es que no hay un recurso de inicio de sesión correspondiente por así decirlo? ¿O fuerza algo más que me estoy perdiendo?
Nota: si uno crea sesiones con ellos, es un asunto completamente diferente. Estoy más interesado en saber "por qué" ¿están calificados como tranquilos? El solo googlear para "Autenticación basada en formulario frente a autenticación reparadora" produce bastantes resultados.
Uno podría usar estos "formularios" para autenticar y pasar tokens para que la aplicación los almacene en cookies, etc., lo cual creo que es completamente tranquilo (asumiendo seguridad criptográfica, etc.), ...
De esta respuesta :
Para ser RESTful, cada solicitud HTTP debe llevar suficiente información por sí misma para que su destinatario la procese para estar en completa armonía con la naturaleza sin estado de HTTP.
No es que la autenticación basada en formularios no sea REST. No es REST. Tener sesión en absoluto . La forma REST es enviar credenciales con cada solicitud. Sin embargo, esto podría ser fácilmente escuchado, pero HTTPS / SSL / TLS cierra ese agujero.
Excelente pregunta. Creo que los puristas RESTful probablemente dirán que tener un URI asociado con una acción en lugar de un recurso es lo que hace que la autenticación basada en formularios no sea RESTful, que es algo que usted mismo señaló.
Sinceramente, creo que la idea de una aplicación RESTful 100% pura es un ideal utópico cuando se trata de aplicaciones web. Sin embargo, creo que es factible para los servicios web RESTful, ya que las aplicaciones que llaman pueden pasar credenciales con el encabezado de la solicitud.
Al final del día, creo que siempre y cuando su aplicación funcione , está bien, y no debe preocuparse por si es o no puramente REST.
Ese es mi $ 0.02.
La autenticación basada en formularios no utiliza las técnicas de autenticación integradas en HTTP (por ejemplo, autenticación básica, autenticación de resumen).
Los puristas de REST le pedirán que use la funcionalidad incorporada en HTTP siempre que sea posible. Aunque la autenticación basada en formularios es extremadamente común, no forma parte del protocolo oficial. Por lo tanto, el purista de REST ve la autenticación basada en formularios como una instancia de "creación de funcionalidad sobre HTTP cuando esa funcionalidad ya existe dentro de HTTP ".
No hay nada de malo en enviar sus credenciales, tal vez a través de un formulario, para la autenticación. El problema es que la mayoría de los sistemas basados en formularios dependen de las sesiones, por lo que requieren que solo inicie sesión "una vez".
Las sesiones son el estado del servidor, lo que viola la restricción sin estado de una arquitectura REST.
Si tiene que enviar las credenciales cada vez, puede incluirlas en la carga útil (es decir, mediante un formulario) o puede usar el encabezado de Autorización HTTP.
Si los incluye en la carga útil, puede incluirlos en el cuerpo, pero solo para un POST o PUT, y no un GET o DELETE (ya que no tienen cuerpos).
Si los incluye en la URL como parte de los parámetros de consulta, entonces la URL ya no representa necesariamente el recurso real. Uno de los otros principios es que la URL coincide con el recurso. La adición de información fuera de banda (como las credenciales) dentro de los parámetros de consulta confunde un poco la restricción.
Por lo tanto, para un sistema REST a través de HTTP, es mejor usar el mecanismo de Autorización HTTP existente que trabajar en otra cosa. También puede utilizar certificados SSL específicos del cliente, que también funcionan bien.