Skip to main content
Formato del error Lender devuelve la mayoría de los errores como detalles de problema RFC 9457 con el tipo de medio application/problem+json. Un rechazo por límite de tasa responde con un cuerpo plano {code, title, message} en application/json.
Definiciones de los campos
  • status – El código de estado HTTP.
  • title – El nombre del estado, como Unprocessable Entity.
  • detail – Qué salió mal en esta ocurrencia. Por debajo de 500, describe el rechazo específico. Para 500, 502 y 503, lleva un valor genérico fijo en lugar de la causa subyacente.
  • errors – Lista opcional de detalles de validación de esquema. Cada entrada lleva un location, un message y el value que recibió Lender.
  • type – Presente en los errores que produce el framework, donde lleva el valor predeterminado de RFC 9457 about:blank.
El cuerpo plano del límite de tasa lleva en cambio code, title y message. Su code repite el estado HTTP numérico. Su title nombra el rechazo y su message lo explica en una sola frase. Ninguna de las dos cadenas varía según quien llama, ni indica la cuota que te queda. Ramifica según el estado HTTP y el tipo de contenido, y luego lee detail para conocer el rechazo específico. El middleware de autorización y de idempotencia puede responder en sus propios formatos de respuesta.

​
Errores del cliente

Lender responde con un 4xx cuando el problema es la solicitud, y detail nombra el rechazo específico. Lender limita una búsqueda al tenant de quien llama y al padre nombrado en la ruta. Un identificador que resuelve fuera de ese ámbito responde igual que un identificador que no resuelve a nada. Un comando necesita un subject en la identidad de quien llama, porque Lender registra ese subject como el actor detrás del cambio. Los límites de bytes se aplican dos veces: el framework limita el cuerpo de la solicitud, y cada superficie de ingesta de archivos limita el archivo que acepta. La validación de esquema se ejecuta antes del handler y llena errors con una entrada por cada ubicación rechazada. Una regla de negocio se ejecuta dentro del handler y responde solo con detail. Tres ejemplos: una aserción de moneda que no coincide con el préstamo, una composición de conjunto que mezcla monedas, y un fondo configurado sin registro.

​
Errores del servidor

Lender responde con un 5xx cuando la solicitud es correcta y la llamada no pudo completarse. Para estos estados, detail lleva un valor genérico fijo, de modo que la causa subyacente permanece dentro del servicio. Un 503 cubre dos condiciones: una capacidad que el despliegue no ejecuta, y una dependencia que Lender no puede alcanzar en el momento de la llamada. Un 502 cubre a un tercero que rechaza un comando que Lender le reenvía, como el registro que asienta una cesión de cuentas por cobrar.