200
Ugh ... (309, 400, 403, 409, 415, 422) ... muchas respuestas tratando de adivinar, argumentar y estandarizar cuál es el mejor código de retorno para una solicitud HTTP exitosa pero una llamada REST fallida .
Esta mal mezclar códigos de estado HTTP y códigos de estado REST.
Sin embargo, vi muchas implementaciones mezclándolas, y muchos desarrolladores pueden no estar de acuerdo conmigo.
Los códigos de retorno HTTP están relacionados con el HTTP Requestmismo. Una llamada REST se realiza mediante una solicitud de Protocolo de transferencia de hipertexto y funciona a un nivel inferior al método REST invocado. REST es un concepto / enfoque, y su salida es un resultado comercial / lógico , mientras que el código de resultado HTTP es de transporte .
Por ejemplo, devolver "404 No encontrado" cuando llama a / users / es confuso, porque puede significar:
- URI está mal (HTTP)
- No se encontraron usuarios (REST)
"403 Prohibido / Acceso denegado" puede significar:
- Se necesita un permiso especial. Los navegadores pueden manejarlo preguntando al usuario / contraseña. (HTTP)
- Permisos de acceso incorrectos configurados en el servidor. (HTTP)
- Debes estar autenticado (REST)
Y la lista puede continuar con '500 Server error "(un error de Apache / Nginx HTTP lanzado o un error de restricción comercial en REST) u otros errores de HTTP, etc.
Según el código, es difícil entender cuál fue la razón de la falla, una falla HTTP (transporte) o una falla REST (lógica).
Si la solicitud HTTP se realizó físicamente con éxito, siempre debe devolver el código 200, independientemente de si el registro se encuentra o no. Porque el recurso URI se encuentra y fue manejado por el servidor HTTP. Sí, puede devolver un conjunto vacío. ¿Es posible recibir una página web vacía con 200 como resultado HTTP, verdad?
En lugar de esto, puede devolver 200 códigos HTTP con algunas opciones:
- objeto "error" en el resultado JSON si algo sale mal
- Vaciar matriz / objeto JSON si no se encuentra ningún registro
- Una bandera de resultado / éxito bool en combinación con opciones anteriores para un mejor manejo.
Además, algunos proveedores de Internet pueden interceptar sus solicitudes y devolverle un código HTTP 404. Esto no significa que no se encuentren sus datos, pero es algo incorrecto a nivel de transporte.
De Wiki :
En julio de 2004, el proveedor de telecomunicaciones del Reino Unido, BT Group, implementó el sistema de bloqueo de contenido Cleanfeed, que devuelve un error 404 a cualquier solicitud de contenido identificado como potencialmente ilegal por Internet Watch Foundation. Otros ISP devuelven un error "prohibido" HTTP 403 en las mismas circunstancias. La práctica de emplear errores falsos 404 como un medio para ocultar la censura también se ha informado en Tailandia y Túnez. En Túnez, donde la censura era severa antes de la revolución de 2011, la gente se dio cuenta de la naturaleza de los falsos errores 404 y creó un personaje imaginario llamado "Ammar 404" que representa "el censor invisible".
¿Por qué no simplemente responder con algo como esto?
{
"result": false,
"error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}
Google siempre devuelve 200 como código de estado en su API de geocodificación, incluso si la solicitud falla lógicamente: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
Facebook siempre devuelve 200 para solicitudes HTTP exitosas, incluso si la solicitud REST falla: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling
Es simple, los códigos de estado HTTP son para solicitudes HTTP. REST API es suya, defina sus códigos de estado.