with what tutorial para framework español develop applications rest http http-status-codes

rest - what - tutorial de django



Código de estado HTTP para error de dependencia externa (3)

¿Cuál es el código de estado HTTP correcto para devolver cuando un servidor tiene problemas para comunicarse con una API externa?

Digamos que un cliente envía una solicitud válida a mi servidor A, A y luego consulta la API del servidor B para hacer algo. Sin embargo, la API de B actualmente está lanzando 500 o es de alguna manera inalcanzable, ¿qué código de estado debería devolver A al cliente? Un error de 5 * no parece correcto porque el servidor A funciona como debería y un error de 4 * no parece correcto porque el cliente está enviando una solicitud válida a A.

¿Consideraste los códigos de estado 502 y 504 ?

502 – The server while acting as a gateway or a proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. 504 – The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.

Por supuesto, esto requeriría una interpretación amplia de "pasarela" (implementación de la interfaz A que requiere una llamada a la interfaz B), aplicada a la capa de aplicación. Pero esta podría ser una buena manera de decir: "No puedo responder pero no es mi culpa ni la tuya".

Dado que la API se basa en algo que no está disponible, su servicio tampoco está disponible.

Creo que el código de estado 503: Servicio no disponible es el mejor ajuste para su situación. De la descripción del RFC :

El servidor actualmente no puede manejar la solicitud debido a una sobrecarga temporal o mantenimiento del servidor. La implicación es que esta es una condición temporal que se aliviará después de algún retraso. Si se conoce, la duración del retraso PUEDE indicarse en un encabezado Reintentar después. Si no se da un Reintento después, el cliente DEBE manejar la respuesta como lo haría para una respuesta 500.

Por supuesto, la descripción implica que este código de estado debe aplicarse para errores en el propio servidor (y no para señalar un problema con una dependencia externa). Sin embargo, esta es la mejor opción dentro de los códigos de estado RFC, y no sugeriría usar ningún código de estado personalizado para que cualquiera pueda entenderlos.

Alternativamente, si su API admite una forma de comunicar errores (por ejemplo, para decirle al usuario que el ID que le proporcionó es incorrecto) puede usar este método para decirle que la dependencia no está disponible. Esto podría ser un poco más amigable y podría evitar algunos errores de búsqueda por parte del usuario, ya que al menos algunos de los usuarios no estarán familiarizados con ningún código de estado, además de 403, 404 y quizás 500, dependiendo de su audiencia.