una - tipos de estados http




¿Cuál es la respuesta de código de estado HTTP apropiada para una solicitud general sin éxito(no es un error)? (4)

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.

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?

  1. El cliente POSTS ordena al servidor un recurso de usuario. Si el usuario no existe, se devuelve 404 Not Found.
  2. El formato e información del pedido está validado. Si no es válido, se devuelve 400 Bad Request.
  3. 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 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.


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.

https://httpstatuses.com/422





http-status-codes