Interfaces abiertas. Límites claros.

No. Complementa la comprobación de seguridad de la aplicación. Los permisos de negocio y el procesamiento seguro de los datos deben implementarse en los servicios responsables.

Sí, si se acuerdan el alcance y el acceso a los datos. Planificamos medios de acceso independientes, datos de prueba adecuados y una vía de aprobación para producción.

Los socios y las aplicaciones necesitan interfaces en cuyo comportamiento puedan confiar. Diseñamos los contratos de API, configuramos el acceso y la protección en el gateway, y organizamos las versiones, la documentación y las aprobaciones durante todo el ciclo de vida.

Guía de API con convenciones de nomenclatura, formatos de error, versionado y requisitos de seguridad Catálogo de interfaces con especificación OpenAPI y responsable por API Creación del gateway con Kong, Apigee o Azure API Management, conectado a su gestión de identidades mediante OAuth 2.0 y OpenID Connect Portal para socios y desarrolladores con gestión de accesos, claves e informes de uso Ciclo de vida con proceso de aprobación, retirada de versiones antiguas y notificaciones de cambios

Guía de API y catálogo de interfaces Gateway de API operativo conectado a la gestión de identidades Portal para desarrolladores con documentación por API

Empezamos con los procesos de los sistemas conectados: ¿qué datos necesitan, qué estados pueden modificar y cómo detectan los errores? REST, GraphQL o gRPC se eligen según el caso de uso. La descripción utiliza el formato adecuado para el protocolo, por ejemplo OpenAPI para las API HTTP correspondientes. Además de la carga útil, se definen la paginación, los límites de tiempo, las respuestas de error y el comportamiento ante reintentos. Los ejemplos y los casos de prueba ayudan a los equipos consumidores a integrar la interfaz antes de la aprobación para producción.

Un gateway puede gestionar los accesos, limitar las solicitudes y aplicar reglas técnicas. Además, debe ser el servicio responsable quien decida si un usuario concreto puede leer un pedido determinado. Planificamos la comprobación de tokens, las identidades de servicio, la asignación de inquilinos y el registro a lo largo de este límite. En las llamadas de escritura se define cómo se tratan las solicitudes repetidas. Las versiones antiguas reciben un proceso de retirada claro, para que los cambios no interrumpan de forma inesperada las conexiones con los socios.

Las pruebas de contrato comprueban la estructura acordada; las pruebas de integración y de carga cubren además el comportamiento. Probamos los accesos denegados, las entradas no válidas y los tiempos de espera agotados, así como las llamadas correctas. El traspaso incluye la especificación, la configuración del gateway y las responsabilidades. Para empezar necesitamos los consumidores típicos, las hipótesis de carga y los procesos de negocio que la API debe hacer posibles.

Diseñamos las API de forma que los equipos internos y los socios externos puedan utilizarlas con fiabilidad. Esto incluye un contrato comprensible, permisos de acceso claros y una operación que gestiona de forma visible los errores y la sobrecarga.

Los accesos no autorizados a objetos se prueban de forma explícita. El contrato de la API y su implementación coinciden en los casos acordados. La sobrecarga y los fallos generan respuestas documentadas.

Ejemplo: los socios comerciales deben poder consultar el estado de sus pedidos. Ponemos a disposición una API delimitada, asignamos los accesos a la organización correspondiente y protegemos el ERP frente a una carga no controlada. Los cambios de estado internos se traducen en respuestas externas estables.

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.

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.

Mapa de sistemas, flujos de datos, cuellos de botella Área de negocio, operación de TI, arquitectura, arquitecto de integración de OTOKO® Inventario de interfaces, riesgos evaluados, casos de integración priorizados

Arquitectura de integración, catálogo de interfaces, modelo de operación Arquitectura, seguridad de la información, protección de datos, área de negocio Arquitectura objetivo, propiedad de los datos por objeto, requisitos de seguridad, modelo de operación