Servicios como una plataforma o tu aplicación sobre APIs de terceros

Los tiempos han cambiado desde que uno acabó la carrera y empezó a dedicarse al desarrollo software. Al modelo de control total en el que desde el servidor de base de datos hasta la capa de presentación – junto a los distintos sistemas a los que se conecta la aplicación que desarrollamos – quedan bajo nuestro control que le han aparecido distintas alternativas, que me gustaría repasar en distintos posts sucesivos. El primero de ellos es el modelo de desarrollo con uso de APIs de terceros, los conocidos como mashups o aplicaciones web híbridas.

La clave y gran ventaja de los mashups radica en la integración de funcionalidades propias con datos de terceros, que proveen de una API para tal menester. Si comparamos el coste de desarrollar un servicio de mapas navegable con utilizar el API de Google Maps o crear una plataforma de vídeos con «tirar» de Youtube, la segunda opción se presenta como mucho más conveniente. Las APIs de terceros se están configurando como las librerías de la programación clásica, pero con diferencias importantes que hay que tener en cuenta antes de lanzarnos a construir nuestra aplicación sobre servicios de terceros.

  1. La primera y clave es que las condiciones de uso de la API deben estar claras y por escrito. Lo peor que nos puede pasar es que nuestro servicio tenga éxito y de repente el proveedor se descuelgue pidiendo un dineral por «exceso de uso». Antes de nada, nos conviene revisar concienzudamente la licencia de la API, a qué se compromete cada parte y con qué limitaciones. Idealmente, tener un contrato sería lo que más nos conviene.
  2. Relacionada con la anterior, debe quedar claro con qué tiempo y cómo comunicarían un cambio en la API. En el modelo de desarrollo con control total, si un proveedor cambia de versión tienes tiempo para reaccionar. Supongamos que Oracle ofrece una actualización, tiene uno la posibilidad de probarla en un entorno de desarrollo, modificar nuestra aplicación si es necesario y finalmente «subirlo todo a producción». Con el modelo basado en APIs de terceros, si nuestro proveedor cambia el interfaz de la misma, nos quedamos con la aplicación fallando a los usuarios, un desastre.
  3. El modelo de negocio de nuestro proveedor es importante. Hablamos de ello cuando Microsoft presentó las APIs de Windows Live. Por un lado porque para la viabilidad de nuestro servicio necesitaremos hacer cuentas sobre lo que nos cobrarán si crecemos, por otro porque un proveedor que da gratis una API de forma ilimitada y sin modelo de negocio es muy sospechoso, puede que no dure demasiado.
  4. A la hora de elegir API debemos tener en cuenta además temas como la disponibilidad, el escalado y el tiempo de respuesta. Idealmente deberían estar reflejados en el contrato con el proveedor, pero en todo caso hay que tenerlos presentes antes de montar un negocio sobre la API del servicio del vecino de arriba que lo aloja en casa.
  5. Debemos tener un segundo proveedor bajo la manga. Los principios de programación modular siguen siendo aplicables, tengamos las llamadas a la API es una clase o módulo determinado, de forma que si queremos cambiar proveedor sólo haya que tocar en un sitio. ¿Qué Google Maps de repente no es el mejor servicio o han hecho un cambio que no nos cuadra? ¿Que nuestro proveedor desaparece? Tener estudiada la posibilidad de pasarse a otro proveedor nos puede ahorrar más de un trauma.
  6. Hay que añadir valor más allá de lo que ofrezca la API. Panoramio necesitaba los mapas, pero la clave era el geoposicionamiento de las imágenes y la comunidad alrededor; My Strands.TV utiliza los vídeos de Youtube pero su valor fundamental es el sistema de recomendaciones. Siempre hay que contar con que lo hayamos construido sobre el servicio de un tercero puede ser replicado por sus responsables, pero si nos especializamos en hacer algo valioso para los usuarios es probable que sobrevivamos.
  7. Legalidad. En España hay que tener en cuenta la LOPD y la LSSI-CE, sobre todo si además de leer, «escribimos» en el servicio de un tercero. De igual forma, hay contenidos cuya distribución es legal en el país del proveedor de la API, pero no el que estemos construyendo nuestra aplicación.

A pesar de las numerosas objeciones mencionadas, no comparto las visiones conservadoras de que no se puede montar un negocio utilizando servicios de terceros. El ahorro de costes, de tiempo y el poder utilizar al mejor proveedor del mundo en cada especialidad son motivos más que suficientes para considerar a los servicios como una plataforma y crear tu aplicación sobre APIs de terceros. La guerra por convertirse en el socio de los nuevos emprendedores y permitir el uso de sus servicios está sobre la mesa. Actores como Microsoft y Google se disputan a los programadores junto a una larga lista (Programmable). Eso sí, lapropuesta de Amazon y sus web services la considero de una manera diferente y protagonizará el siguiente post de la saga.

Enlaces relacionados:

Los comentarios están cerrados.