Restricción única en una arquitectura RESTFul

Question

Con 15 años de experiencia en el desarrollo de software cliente-servidor con estado (y sus problemas inherentes), sigo intentando comprender el concepto de apatridia en una arquitectura RestFul.

Supongamos que tengo una interfaz genérica para publicar objetos comerciales en mi servicio REST. Por ejemplo, recursos de usuario. Mi recurso de usuario debe tener una restricción sobre la singularidad de su dirección de correo electrónico. Mi reacción inicial sería utilizar las instalaciones de bases de datos subyacentes para "garantizar" esto. La segunda reacción sería introducir algún mecanismo de bloqueo o transacción.

Pero mi colega Restafarian responde: '¡No!' El cliente debe verificar si el correo electrónico para el nuevo usuario es único y debe aceptar el hecho de que hay un pequeño intervalo de tiempo en el que se puede insertar una dirección de correo electrónico duplicada. La aplicación cliente debe ser capaz de manejar este conflicto.

Esto, a su vez, va en contra de todo lo que he aprendido y no se siente natural en absoluto. Por favor, ilumíname ...

Answer 1

No veo ninguna razón para no devolver el HTTP code: 409 Conflicto apropiado. Esto puede devolverse al obtener errores de su base de datos.

Es bueno por razones de usabilidad para comprobar si la dirección de correo electrónico es única antes de enviar la solicitud, ya que puede solicitar al usuario (y desactivar enviar) para corregir el problema. En cualquier caso, se recomienda la verificación del lado del servidor.

Answer 2

Esto no tiene nada que ver con la falta de protocolo de apatridia. Apatridia solo dice que el servidor no debe ser el único estado relacionado con la sesión de guardado (http://en.wikipedia.org/wiki/Stateless_protocol).

En su caso, los recursos del usuario no son estado de sesión: son recursos persistentes almacenados y expuestos por el servidor. No hay razón para que la apatridia obligue al cliente a hacer esta comprobación (buscando y verificando de manera iterativa todos los recursos del Usuario), y tiene más sentido que el servidor lo haga. Si el servidor realiza esta comprobación como parte de POSTing un nuevo recurso de usuario, o existe un recurso independiente que habilita esta comprobación, básicamente no hace ninguna diferencia ya que el servidor está haciendo esta comprobación de cualquier manera. Si utiliza un recurso por separado para verificar primero si está bien enviar POST un nuevo usuario, y luego hacer una nueva solicitud para realmente hacer el POST, entonces existe la posibilidad de direcciones de correo electrónico duplicadas. En tales casos, el comportamiento esperado es que el servidor notifique al cliente que la solicitud POST ha fallado (usando un código de respuesta HTTP apropiado, tal como lo haría con la primera solicitud por la cual el cliente verificó que el correo electrónico es correcto).

En resumen: el servidor hace la "comprobación", y el cliente debe poder manejar las situaciones en las que el servidor notifica que la verificación falló.