¿Deben usarse las cookies en una API RESTful?

Un servicio ReSTful ideal permite a los clientes (que pueden no estar en el navegador) realizar cualquier tarea necesaria en una solicitud ; porque todo el estado necesario para hacerlo lo tiene el cliente, no el servidor. Dado que el cliente tiene el control total del estado, puede crear el estado por sí solo (si es legítimo), y solo hablar con la API para "hacerlo".

Requerir cookies puede hacer eso difícil. Para los clientes además de los navegadores, administrar cookies es un inconveniente bastante grande en comparación con los parámetros de consulta, los encabezados de solicitud simple o el cuerpo de la solicitud. Por otro lado, en el navegador, el uso de cookies puede hacer muchas cosas mucho más simples.

Por lo tanto, una API podría buscar primero en el encabezado Authorization los datos de autenticación que necesita, ya que es probablemente el lugar donde los clientes que no utilizan el navegador preferirán colocarla, pero para simplificar y simplificar los clientes basados en el navegador, podría también busca una cookie de sesión para el inicio de sesión del lado del servidor, pero solo si falta el encabezado regular Authorization .

Otro ejemplo podría ser una solicitud compleja que normalmente requiere muchos parámetros establecidos. Un cliente no interactivo no tendría problemas para incluir todos esos datos en una sola solicitud, pero una interfaz basada en un formulario HTML podría preferir dividir la solicitud en varias páginas (algo así como un conjunto de páginas de "asistente") para que los usuarios no se presenten. con opciones que no son aplicables en base a selecciones anteriores. Todas las páginas intermedias podrían almacenar los valores en las cookies del lado del cliente, de modo que solo la última página, en la que el usuario envía la solicitud, tenga algún efecto del servidor. La API podría buscar los atributos necesarios en el cuerpo de la solicitud y volver a mirar las cookies si los parámetros necesarios no estuvieran allí.

Editar: en RE al comentario de @ Konrad a continuación:

  

Los tokens en comparación son más difíciles de implementar, especialmente porque no se puede invalidar fácilmente el token sin almacenarlos en algún lugar.

er ... está validando las cookies en el lado del servidor, ¿verdad? Solo porque le dijo a que el navegador descarte una cookie después de 24 horas no significa que lo hará. Esa cookie puede ser guardada por un usuario altamente técnico y reutilizada mucho después de que haya "caducado".

Si no desea almacenar los datos de la sesión en el lado del servidor, debe almacenarlos en el token (cookie o de otra manera). Un token de autenticación autocontenido a veces se denomina Macaroon. Cómo se pasa entre el cliente y el servidor (ya sea por cookie, como extra los encabezados, o en la entidad de solicitud en sí) es totalmente independiente del propio mecanismo de autenticación.

Sí y No: depende de cómo lo uses.

Las cookies, si se utilizan para mantener el estado del cliente en el cliente, para el cliente, del cliente y por el cliente, son tranquilas.

Si está almacenando el estado del servidor en la cookie, básicamente está cambiando la carga al cliente, lo que no es reparador.

Entonces, ¿cuáles son algunos ejemplos?

Descansa:

• Detalles de la autenticación o 'está conectado' algo así como.
• última página vista o lugar en la aplicación, etc.

No descansa:

• Almacenamiento de información de sesión

La tranquilidad proviene de la falta de estado del servidor. Los clientes pueden mantener el estado de la aplicación y enviarla al servidor para indicar dónde están, de modo que el servidor pueda decidir a dónde ir. Básicamente, las sesiones / estados necesitan datos históricos y dependen de solicitudes pasadas, por así decirlo, idealmente las aplicaciones de descanso no lo son (no es viable tener una aplicación de descanso del 100% si va a tener una pantalla de inicio de sesión :)

Uno puede usar cookies. REST los permite.

REST requiere que la información de la sesión se almacene en el lado del cliente, pero cuando se trata de autenticación, parte de la información debe permanecer en el lado del servidor por razones de seguridad.

De uno de mis blogs posts , existe un acuerdo general de que Los datos de autenticación se consideran fuera del alcance de REST. Por lo tanto, está bien que los servidores mantengan algunos de los datos de esta sesión de su lado.