Las APIs están de moda, no hay duda. No hay nadie que se precie en sacar un producto o aplicación al mercado sin sacar también su API asociado. Al fin y al cabo, las APIs son el pegamento de internet, el que hace que piezas heterogéneas puedan funcionar juntas y creando modelos de valor nuevos, que en muchos casos, ni siquiera el dueño de este API se había imaginado. Y para muestra, el reciente lanzamiento del API de Lemonade.

Pero como muchas veces pasa, nos olvidamos de lo más básico. ¿Qué significa API? no hay que olvidar en ningún momento que significa Application Programming Interface… es decir, al fin y al cabo, un API es para el programador.

Y ahora seamos autocríticos.. Cuando diseñamos un API ¿estamos teniendo verdaderamente en cuenta a quien lo va a consumir? Me temo que no.

Como muchas veces ocurre, el programador, el developer es el gran olvidado de la fiesta. Hablamos de UX, hablamos de Alta disponibilidad, de facilitar los despliegues, los logs, etc. pero ¿dónde está la facilidad de uso de un API?.

Developer Experience en APIs

Podemos definir la DX como la suma de experiencias que tiene un developer al usar un API, lo cual suena bastante obvio pero que se traduce en varios “must have” que nuestro API debe tener.

Podemos estar en el caso en que nuestra empresa esté compitiendo con otras similares y que tenga que ganarse un hueco en el corazón y la mente del desarrollador. Estoy pensando por ejemplo en un  API de metereología o de geoposicionamiento… a igualdad de condiciones, ¿cuál elegiremos? la que mejor experiencia nos dé.

Quizás en el caso de un API de una gran empresa esto no ocurra tanto, porque normalmente las APIs estas grandes empresas son consumidas por otras empresas con las que se tienen un acuerdo comercial y son un “sí o sí”. Da igual el aspecto y experiencia que tenga este API, hay que consumirlo porque tenemos que hacer negocio con ella. Aún en este caso, una buena experiencia de API se traduce en algo fundamental: menos tiempo de desarrollo, menos esfuerzo y menos errores.

Así, pues ¿qué tiene que tener un API para que el desarrollador la quiera usar? Dos cosas básicas y alguna característica deseable:

Empatía

Si queremos que nuestro API sea un buen producto, cuyos usuarios quieran usarlo, tenemos que hacer un gran esfuerzo de empatía.. ponernos en su lugar. Así creo que uno de los primeros pasos que hay que dar es convertirnos en nuestros propios usuarios (comer nuestra comida de perro) y usar el API (a ser posible una persona que no haya tenido relación con el propio API)

Funcionalidad

Aunque suene un poco raro al decirlo, nuestras APIs tienen que ser poderosas. Tienen que tener una gran funcionalidad y además tiene que molar. ¿O no mola, por ejemplo, que al invocar un servicio REST puedas mandar una grúa a cualquier punto del país para recoger un coche averiado?… puro poder 😉

Características fundamentales de un API con buen DX

Documentación

Y no me refiero al clásico documento de tropecientas páginas que se queda obsoleto nada más publicarlo. La documentación tiene que estar constantemente actualizada y estar viva. Y cuidar los detalles, como un buscador que funcione y encuentre lo que buscas.

Y tiene que estar viva porque debe permitir hacer pruebas online, probando la invocación con diferentes parámetros y viendo los resultados.

La documentación también tiene que contemplar ejemplos, y documentos del tipo Hola Mundo y Getting Started que les quite el primer miedo a lo desconocido a nuestros potenciales usuarios.

Utilidades

Aunque represente mucho más trabajo hay que plantearse la creación de un SDK para el uso del API en lugar de hacer tratar al desarrollador únicamente con llamadas HTTP.

Sandbox

Considero un sandbox vital para el éxito de un API. Un entorno donde se pueda jugar sin peligro y de manera fácil y que luego se pueda cambiar al entorno de producción sin esfuerzo.

Hay que recordar que los entornos empresariales no suelen ser todo lo ágiles que nos gustaría. Si vamos por una concepción digamos tradicional, tendríamos que pedir usuarios para acceder al entorno de pruebas, solventar el problema del tratamiento de datos, de la propia conexión física (es posible que incluso nos obliguen a usar una VPN), etc. etc.

Si queremos que la experiencia del desarrollador sea buena, darse de alta para usar un API y disponer de un sandbox para hacer pruebas debería ser cómo comprar una película en un Google Play, una serie de pasos sencillos y que nos de acceso en minutos.

Conclusión

Por favor, no olvidemos nunca que el usuario de nuestra API va a ser el desarrollador. Tenemos que velar porque su uso no le resulte un pain in the ass, al contrario cuidar los detalles para que la experiencia sea la mejor posible.

Anuncios