tipos - success http status codes
¿Cuál es la respuesta de código de estado HTTP apropiada para una solicitud general sin éxito(no es un error)? (6)
Estoy creando una API RESTful que procesará varias interacciones del usuario, incluida la realización de pedidos con tarjetas de crédito almacenadas.
En el caso de un pedido exitoso, devuelvo un 200 OK, y en el caso donde la solicitud de pedido está mal formada o es inválida, devuelvo una 400 Bad Request. Pero, ¿qué debo devolver si hay un problema durante el procesamiento real del pedido?
- El cliente POSTS ordena al servidor un recurso de usuario. Si el usuario no existe, se devuelve 404 Not Found.
- El formato e información del pedido está validado. Si no es válido, se devuelve 400 Bad Request.
- Orden es procesada Si la orden es exitosa, se devuelve un 201 Creado para la orden. Si se encuentra un error inesperado, se devuelve un error de 500 Server.
El último paso es el problema: ¿qué debo devolver si el pedido no se completa por alguna otra razón? Los posibles escenarios podrían incluir:
- El producto está agotado
- Límite máximo de pedido del usuario alcanzado
- Fallo en la transacción de la tarjeta de crédito (fondos insuficientes, etc.)
Esto no parece ser apropiado para 400 o 500. En todo caso, podría verlo como 400 si no hay un código mejor; la solicitud no era válida de acuerdo con las reglas comerciales. Simplemente no parece exacto.
Editar: También encontré esta discusión existente sobre el mismo tema. Todas las respuestas parecen apuntar a usar códigos de estado para este tipo de violación, con alguna discusión entre usar 400, 409 o la extensión 422.
Debe usar 400 para reglas comerciales. No devuelva 2xx si la orden no fue aceptada. HTTP es un protocolo de aplicación, nunca lo olvides. Si devuelve 2xx, el cliente puede suponer que el pedido fue aceptado, independientemente de la información que envíe en el cuerpo.
Del libro de cocina de RESTful Web Services :Un error común que cometen algunos servicios web es devolver un código de estado que refleja el éxito (códigos de estado de 200 a 206 y de 300 a 307), pero incluye un cuerpo de mensaje que describe una condición de error. Al hacerlo, evita que el software consciente de HTTP detecte errores. Por ejemplo, un caché lo almacenará como respuesta exitosa y lo servirá a los clientes subsiguientes, incluso cuando los clientes puedan hacer una solicitud exitosa.
Dejaré que decidas entre 4xx y 5xx, pero deberías usar un código de estado de error.
Debe usar 4xx para un error de cliente si el cliente puede modificar la solicitud para evitar el error. Use un 5xx para un error de servidor que el cliente realmente no puede solucionar.
El producto agotado sería un error del servidor. El cliente no puede modificar la solicitud de alguna manera para evitar el error. Podría cambiar a otro producto pero ¿no sería una nueva solicitud?
El límite máximo de pedido alcanzado por el usuario también es un error del servidor. Nada que el cliente pueda hacer para evitar ese error.
La falla de la transacción de la tarjeta de crédito sería un error del cliente. El cliente puede volver a enviar la solicitud con un método de pago o número de tarjeta de crédito diferente para evitar el error.
No creo que 400 se pueda usar para todo el escenario de negocios. Se puede utilizar para la validación de entrada de datos básicos. Más allá de eso, podríamos tener dificultades para ajustar la lógica de otros negocios en este código de error. El error manejado por esto son principalmente errores de tiempo de diseño que el desarrollador encontrará posiblemente durante la codificación del cliente.
Digamos que todos los parámetros son correctos y digamos que estamos pasando el número de cuenta de usuario a la solicitud.
Entonces la solicitud ya no es una mala solicitud, el servidor puede aceptar la solicitud. Pero ahora se niega a completar la solicitud en función de la nueva información disponible, que es: la cuenta no tiene saldo suficiente.
Sugeriría que usemos 403 con el mensaje de error apropiado en esos escenarios.
Otro posible código de error podría ser 409 conflicto. Pero eso se usa en escenarios donde el recurso se encuentra en estado consistente.
Sé que esta pregunta es antigua, pero se me ocurrió la misma pregunta hoy. Si mi usuario se queda sin créditos, ¿qué código de estado debe devolver mi API REST?
Tiendo a inclinarme hacia 402 Payment Required :
De acuerdo con Wikipedia :
Reservado para uso futuro. La intención original era que este código se usara como parte de alguna forma de efectivo digital o esquema de micropagos, pero eso no ha sucedido, y este código generalmente no se usa. La API de Google Developers usa este estado si un desarrollador en particular ha excedido el límite diario de solicitudes.
Y de hecho lo hacen :
PAYMENT_REQUIRED (402)
- Se ha alcanzado un límite de presupuesto diario establecido por el desarrollador.
- La operación solicitada requiere más recursos de los que permite la cuota. El pago es requerido para completar la operación.
- La operación solicitada requiere algún tipo de pago del usuario autenticado.
Tipo de error:
4×× Client Error
Código de error:
422 Unprocessable Entity
El servidor entiende el tipo de contenido de la entidad de solicitud (por lo tanto, un código de estado 415 Tipo de medio no admitido es inapropiado) y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un código de estado de 400 solicitudes incorrectas es inapropiado) pero no pudo procesar el instrucciones.
Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas) pero semánticamente erróneas.
Voy con 406 Not Acceptable .
Aquí hay una lista 4xx:
const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418; // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421; // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422; // RFC4918
const HTTP_LOCKED = 423; // RFC4918
const HTTP_FAILED_DEPENDENCY = 424; // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425; // RFC2817
const HTTP_UPGRADE_REQUIRED = 426; // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428; // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429; // RFC6585