API

Una API es la forma definida en que una pieza de software habla con otra. Dice: aquí están las cosas que puedes pedirme que haga, aquí está exactamente cómo lo pides, y aquí está lo que recibes de vuelta. Todo el sentido es que quien llama no necesita saber cómo se hace el trabajo internamente, solo qué enviar y qué esperar. La app del tiempo de tu teléfono no sabe cómo funciona el servicio meteorológico. Solo conoce la API, envía una petición y recibe un pronóstico.

La idea clave es el contrato. Ambos lados se ponen de acuerdo sobre la forma de las peticiones y las respuestas, y mientras ese contrato se mantenga, cada lado puede cambiar sus interioridades libremente. Los dos estilos comunes de los que oirás hablar son REST, que modela todo como recursos que lees y escribes mediante peticiones web estándar y es el predeterminado para la mayoría de los backends web y móviles, y GraphQL, que permite a quien llama pedir exactamente los campos que quiere en una sola petición. Ambos son solo formas disciplinadas de definir el mismo contrato.

El diseño de API es una de las decisiones más duraderas que tomas. El código interno lo puedes refactorizar en un fin de semana. De una API pública depende el software de otras personas en su forma exacta, así que cambiarla rompe sus integraciones, lo que significa que a menudo no puedes cambiarla en absoluto sin un doloroso ejercicio de versionado. Una API limpia, bien nombrada y consistente envejece bien. Una descuidada se convierte en un impuesto permanente que pagas en cada cambio futuro. Tratamos el diseño de API como una parte de primera clase del desarrollo de software, no como una ocurrencia tardía atornillada al final.

La opinión honesta: la mayoría de las quejas de “la integración es una pesadilla” se remontan a una API diseñada con prisa para entregar una funcionalidad, y luego forzada a cargar con diez. Invierte el tiempo en el contrato pronto. Es la parte que menos podrás cambiar después.