Interfaces abiertas. Límites claros.

De la función de negocio a un contrato de API estable

Una API debería ofrecer una función de negocio comprensible y no exponer sin filtrar las tablas de un sistema interno. Definimos recursos, acciones, campos obligatorios y respuestas de error junto con los equipos consumidores. Los datos de ejemplo y una descripción legible por máquina facilitan la integración; las reglas de negocio quedan documentadas de forma explícita.

Los cambios se evalúan según su impacto. Un campo opcional adicional se trata de forma distinta a un nuevo valor obligatorio o a un cambio de significado. Planificamos el versionado, los plazos de transición y la comunicación a los usuarios conocidos. Así, una actualización interna de la base de datos no tiene por qué provocar fallos en todas las aplicaciones conectadas al mismo tiempo.

Proteger conjuntamente el gateway, las identidades y el backend

En el gateway pueden implementarse reglas centrales de autenticación, limitación de volumen y enrutamiento. No obstante, la autorización de negocio debe comprobarse en el servicio responsable: un cliente correctamente autenticado no debe poder leer automáticamente los registros de otro cliente. Por eso analizamos toda la cadena de la solicitud.

Para la operación, acordamos presupuestos de tiempo de respuesta, tiempos de espera y el tratamiento de los reintentos. Los identificadores de correlación conectan los registros de varios sistemas sin registrar de forma indiscriminada el contenido sensible de las solicitudes. Un acceso para desarrolladores con ejemplos y un entorno de pruebas adecuado ayuda a los socios a detectar errores antes de la conexión en producción.