Diseño de API e Integración de Sistemas de Terceros

Dos ingenieros miran la misma API. Uno la está diseñando; el otro intenta integrarla. Están haciendo el mismo trabajo desde lados opuestos del mismo contrato — y casi ningún curso lo enseña de esa manera. Este sí lo hace. Ya haces llamadas a endpoints HTTP. Lo que quizás nunca te han enseñado es el arte subyacente: por qué un POST reintentado cobra silenciosamente dos veces a un cliente, por qué tu "v2" rompió a todos los consumidores la mañana que se lanzó, por qué el flujo OAuth que copiaste de un blog confía en un token que nunca verificaste realmente. Estos no son errores exóticos. Son el resultado predeterminado de tratar una API como "solo llámala". Así que construimos los primitivos duraderos en lugar del SDK de un proveedor. Del lado del diseño: recursos y códigos de estado que significan lo que dicen, errores legibles por máquina (Problem Details, RFC 9457), claves de idempotencia, paginación que sobrevive a un conjunto de datos en movimiento, un contrato OpenAPI que puedes versionar sin traicionar a las personas que dependen de él. Del lado de la integración: un cliente con tiempos de espera reales, reintentos con backoff y jitter, interruptores automáticos, webhooks que verificas y deduplicas antes de confiar, una capa anticorrupción para que un cambio de esquema de un proveedor no se propague por tu código, y credenciales que realmente puedas rotar. En el camino resolvemos las cosas que cambiaron mientras nadie te lo decía: autenticación no es autorización, un token de ID no es un token de acceso, PKCE ahora es obligatorio, un JWT está firmado pero es legible — así que lees las especificaciones en lugar de leyendas. Termina donde lo hace el trabajo real: una integración de pagos y una API pública, construidas de principio a fin, y una lista de verificación que puedes ejecutar en cualquier cosa.