estoy creando una API REST para la creación de usuarios que hace cumplir direcciones de correo electrónico únicas:¿Qué código de respuesta HTTP para "Este correo electrónico ya está registrado"?
éxito POST /users: HTTP 201 Created
Si POST la misma dirección de correo electrónico de nuevo, lo que debería ser el código de respuesta? ¿Es 409 Conflict el código de respuesta apropiado?
Sí, 409 es el más apropiado código de respuesta aquí. Aunque es muy probable que regrese 201 en éxito, todavía está POSTING a un recurso que se describe como una colección, y POSTing un correo electrónico duplicado es definitivamente un conflicto con "el estado actual del recurso" como una colección. Debe devolver un cuerpo de respuesta con una descripción del problema e hipervínculos para ayudar a resolver el problema, si es posible.
¡Gracias por confirmar mi corazonada con la explicación! No pensé en la parte de hipervínculos, definitivamente descubriré una buena manera de incluir eso. – thatmarvin
menudo uso la (extensión WebDAV) HTTP 422Unprocessable Entity: estaba bien formada-
La solicitud, pero no pudo ser seguida debido a errores semánticos
Esta parte me hace pensar que 422 es inapropiado: "... pero no pudo procesar las instrucciones contenidas". Aquí, no hay ambigüedad con respecto a la semántica de las instrucciones: el servidor entendió la solicitud, simplemente no va a cumplirla.(Además prefiero usar códigos RFC 2616 si puedo evitarlo) – thatmarvin
Si bien la respuesta aceptada es correcta al mostrar el código de estado correcto para la tarea, deseo agregar que está presentando una vulnerabilidad de seguridad.
Si devuelve un 409 para el registro de la cuenta, solo está exponiendo un servicio para la enumeración de la cuenta.
Depende de la aplicación, si la API es pública o no, etc., es posible que desee devolver un 201 aunque la cuenta no se haya creado.
+1 a Barts answer - por razones de seguridad. Por lo general, estoy de acuerdo con que 409 es un buen código de estado para sth. eso ya existe Pero en un entorno de cuentas de usuario/autenticación/autorización, etc., tendería a no exponer las cuentas de usuario existentes en su base de datos.
Por supuesto, hay otros mecanismos para manejar la seguridad en este lugar. Si no le importa exponer un pequeño número de sus cuentas, puede agregar un comportamiento a su aplicación que devuelva 401 o 403 en numerosos 409 eventos desde una IP.
Otra opción (en general) es definir un código de estado por su cuenta para tener un 2xx que difiere de las variantes estándar existentes 2xx. Esta podría ser una opción si no desea manejar un "ya existe" como un error. Sin embargo, esto sería considerado como no estándar y tendría el mismo carácter inseguro como un 409 en su ejemplo concreto.
No creo que sea una buena idea. Si la conexión se realiza a través de un proxy, los resultados pueden ser impredecibles. – Cheery
¡Creo que es una buena idea! Debido a que HTTP tiene código de estado, ¡úsalos! También es muy útil cuando tiene que depurar más tarde y solo tiene acceso a archivos u otros archivos de registro, pero si existe el código HTTP ... :) – powtac
'409 - Conflict' es una muy buena opción para este tipo de respuesta. –