Hoy cada vez es más frecuente que programemos determinados comportamientos en una web usando APIs Rest o servicios web de terceros. Incluso es común encontrar aplicaciones web completas que están basadas en APIs de terceros, como es el caso del API de Twitter o el API de Facebook, por poner dos ejemplos de API utilizadas con especial frecuencia. Para hacernos una idea de este tipo de proyectos, basta nombrar plataformas tan conocidas como Tweetdeck, Hootsuite o Bufferapp, que trabajan con el API de Twitter u otros de redes sociales.

En este artículo vamos a relatar una buena práctica que te facilitará disponer de un desarrollo más mantenible cuando estás trabajando con un API de terceros, sobre el que no tienes control. Se trata de crear una interfaz propia que centralice todo el trabajo, de modo que si cambia el API del tercero, solo tengas que cambiar la programación de esa interfaz propia.

Esta buena práctica no es algo que nos estemos inventando ahora. Ya tiene nombre y es un patrón de diseño de software comúnmente aceptado y usado. Se trata del patrón de diseño "Adapter" y en líneas generales se usa para proveer una interfaz de programación de un sistema al que no tienes acceso. Es como un "puente de acceso" a funcionalidades residentes en sistemas externos.

Problemática cuando basamos nuestro desarrollo de negocio en un API

Se dice que si desarrollas un negocio basado en la plataforma de una empresa o red que no depende de ti, estás "vendido". El problema cuando trabajas con API que no controlas es que en cualquier momento te pueden cambiar ese API y con ello te obligan a cambiar tu código fuente.

Imagina tener un proyecto que consume el API de Twitter para implementar una funcionalidad nueva para un negocio online que has ideado. Tu aplicación consume y envía tuits, trabaja con listas de usuarios y todo lo que se te pueda ocurrir. Probablemente en tu gran aplicación tendrás miles de líneas de código que trabajan con el API de Twitter.

Ahora imagina qué pasaría si actualizan el API y te cambian radicalmente la manera de comunicar con ella, ¿qué pasaría con tu proyecto? Pues probablemente estarías "vendido" y necesitarías cambiar rápidamente todas las líneas de código que trabajan con el API para adaptarlas a las nuevas maneras de uso. Esto te puede ocasionar cientos de horas de trabajo o una inversión extraordinaria que no habías previsto.

Si no tenemos bien planificado el proyecto a nivel de desarrollo probablemente nos encontremos en una difícil situación que nos obliga a ser muy minuciosos revisando una maraña de clases y cientos o miles de líneas de código dispersas por todo el proyecto ¿Te atrae la idea? ¿Quizás sea mejor abandonar el proyecto para dedicarse a plantar patatas y criar gallinas en en una granja?

Afortunadamente, hay maneras en las que podrás mitigar esta problemática y reducir de manera drástica la oleada de mantenimiento de tu aplicación provocada por un cambio en la API.

Envoltura de un API

La idea es crear una envoltura o adaptador para la comunicación con el API. Todas las operaciones de tu aplicación cuando trabaja con el API de terceros las debes centralizar en esa clase de POO que realiza la "envoltura".

De este modo, si te cambian el API, el único sitio donde tendrás que cambiar tu código es en aquella clase que realiza el papel de adaptador. La diferencia es sustancial: sin un adaptador probablemente tengas que cambiar el código de tu aplicación en miles de líneas, dispersas en decenas o incluso cientos de clases. Si tienes una envoltura, será solo cambiar la clase que hace uso del API.

Para darnos una idea mejor sobre esta envoltura puedes consultar esta imagen:

Pseudocódigo de ejemplo de envoltura

Este artículo está más enfocado a explicar el concepto, de modo que puedas entender esta buena práctica y ponerla en marcha si alguna vez implementas un API en tus proyectos. No obstante, vamos a colocar aquí un poco de pseudo-código que nos puede dar una idea más concreta.

Insisto, no se trata de ver cómo es un API en concreto y cuáles son sus métodos y esas cosas, sino más bien ver las ventajas de usar una envoltura.

/uso una supuesta API de Twitter
//tiene los métodos
// get(usuario, num_tuits);
// put(usuario, texto);
$tuits = get("midesweb", 10);
put("midesweb", "otro tuit");
/// ...
$tiuts = get("micromante", 5);
put("micromante", "otro tuit");
// ...
//Puedes estar usando esos métodos en otros miles de líneas de código

Ahora, ¿qué pasa si me cambian los nombres de funciones y le llaman "get_tuits()" y "put_tuits()"?. Realmente, este cambio podría ser tan simple como buscar y reemplazar los nombres de los métodos en todo el código del proyecto, pero cuando te cambian un API no suele ser para cambiarte simplemente los nombres de los métodos, sino para cambiar a veces radicalmente el modo de funcionar, con nuevos métodos, nuevos parámetros, etc.

En este caso tienes que editar todos los sitios donde llamas a las funciones (imagina que tienes miles o cientos de miles de líneas de código).

Si fuiste precavido y te has creado una maravillosa envoltura para trabajar con el API, tendrás algo como esto:

// mi envoltura
function dame_tuits(nombre, cantidad){
  get(nombre, cantidad);
}
function manda_tuit(nombre, tuit){
  put(nombre, tuit);
}
/// Las usas así
$tuits = dame_tuits("midesweb", 10);
manda_tuit("midesweb", "otro tuit");
...
$tiuts = dame_tuits("micromante", 5);
manda_tuit("micromante", "otro tuit");

Ahora, en caso que te cambiasen el API con la que estás trabajando, tienes simplemente que cambiar el código de tu envoltura.

function dame_tuits(nombre, cantidad){
    get_tuits(nombre, cantidad);
}
function manda_tuit(nombre, tuit){
    put_tuits(nombre, tuit);
}

Como dentro de todo el proyecto solo hacías llamadas a tu "adapter" (la envoltura) y no al API directamente, simplemente tendrás que editar unas pocas líneas de código, reescribiendo las operaciones de tu adaptador, para constatar los nuevos métodos, parámetros y uso en general de la nueva API de terceros.

Esto es todo, espero que puedas aplicar esta práctica a cualquier proyecto con el que debas trabajar con un API del que no tienes el control, así como para acceder a cualquier otro tipo de interfaz de programación que no depende de ti directamente.