finger-769300_640

Ya está, ya hemos llegado al punto en que la palabra API es un trending topic como lo podríamos llamar ahora. Ya está en el privilegiado conjunto de palabras totémicas (ahí va otra) como pueden ser el cloud, el big data,el user experience y el gamification.

Pero ¿Qué es un API? En ésta entrada del blog lo trataba hace tiempo. A fin y al cabo un API es una forma de implementar unos servicios SOA… aunque con un matiz particularmente importante: un API, además de proporcionar unos servicios de negocio útiles, está orientado a hacerle la vida más fácil al desarrollador, y no principalmente al desarrollador de nuestra empresa, si no a los de terceras empresas, aquellos que ni siquiera sabemos que existen.

Como en todo, hemos pasado de una era de la escasez (había muy pocos servicios disponibles y se necesita muchos recursos para integrarlos en una aplicación) a una era de la abundancia (hay servicios a mogollón disponibles para su uso, muchos de ellos gratis).

Así pues, ¿cómo podemos lograr que una tercera empresa tenga a bien usar nuestros servicios en su aplicación? Evidentemente, hay que tener en cuenta los factores económicos del uso de estos servicios (empaquetados en un API), pero eso va por su camino. Lo que necesitaremos hacer es crear un API que el desarrollador quiera usar.

Un API implica mimar al desarrollador que quiera usarlo

Quizás una de las más significativas diferencias es el concepto de autoservicio. Hasta ahora cuando una empresa quería que otra usase sus servicios pues se juntaban en una mesa, hablaban de los términos del contrato, del coste, se pasaba un documento con la definición del servicio y la empresa empezaba a desarrollar los programas cliente que los invocan.

Sin embargo con un API, la cosa va más allá y se transforma en totalmente digital. Que quiero decir con esto? Que no hace falta intervención humana ninguna por decirlo así.

El desarrollador que quiere invocar a los servicios entra en el portal del API, utiliza un sandbox, se ve la documentación, y su le gusta elige un plan de uso, da sus datos de pago y se registra como usuario del API. Automáticamente se descarga el software necesario (un SDK) y de la forma más sencilla posible lo integra con su propia aplicación.

Como arquitectos de software, cuando diseñamos un API tenemos que seguir el mas puro estilo developer friendly dándole al desarrollador que tratará con nuestro API todas las facilidades posibles:

  • un API sencillo de entender y de usar
  • un portal del desarrollador con toda la información relevante
  • soporte de problemas, foros, comunidad de desarrolladores
  • entorno de test o sandbox donde se puedan probar todas las funcionalidades sin miedo a romper nada
  • eliminación o reducción a la mínima expresión de todos los trámites burocráticos para poder usar el API: registro, pago, etc.

También implica un cambio de mentalidad

En resumen, aparte de los aspectos propios de la orientación a servicios que se dan por supuestos, un API implica un cambio de mentalidad. Un ponerse en el lugar del desarrollador y, por parte de la empresa que ofrece el API, un baño de realidad… no vas a usar estos servicios porque no te queda más remedio.. vas a usar estos servicios porque te facilito la vida y son los mejores que puedes encontrar entre los cientos de APIs que hay disponibles .

También es necesario otro baño, no menos importante de humildad… nuestra empresa no es la más inteligente y lo sabe todo… publicamos un API para que sean otros los que piensen e inventen nuevas funcionalides y modos de uso.

Anuncios