Una API (de sus siglas en inglés: Application Programming Interface) permite conectar las diferentes partes de un sistema de software. Mediante el uso de APIs podemos acceder a bases de datos (interna) o comunicarnos con otras plataformas (de terceros).

En la documentación de la API se detallan las funciones o métodos que podemos usar (lo que se denomina «hacer una llamada a la API») y la respuesta que obtendremos con cada uno de ellos. Esta respuesta será un estado (OK, error, etc.) o un conjunto de datos que suelen estar en formato JSON.

Es importante tener en cuenta que aunque nuestra herramienta conste de más de un producto digital (web, app, etc.), existe una sola API para todos ellos. Esto hace que todo el conjunto de datos (como el catálogo de productos, usuarios, etc.) esté centralizado y homogeneizado.

Su implementación, documentación y mantenimiento es responsabilidad del equipo de desarrollo, pero todo el equipo que forma parte de la definición y construcción del producto debería estar familiarizado con ella.

En cuanto a integrar nuestro producto o servicio con otros, una API nos permite hacer cosas como añadir un mapa proporcionado por Google Maps, permitir que un usuario se registre en nuestro sistema con su cuenta de Twitter o construir un plugin para Sketch.

Cómo nos afecta a la hora de diseñar

Como diseñadores es muy interesante acceder a la API de nuestro producto o servicio y comprender las respuestas a las llamadas que se usan en cada parte. A grandes rasgos obtenemos respuesta a las siguientes cuestiones: qué datos tengo, en que formato, cómo están organizados y qué puedo hacer con ellos.

Salvo que se trate de un diseño de cero o se plantee un desarrollo completo a partir del rediseño, lo normal es que ya exista una API. Es importante saber si como parte del proyecto se contemplan modificaciones en la API o están fuera de alcance. Así sabremos que grado de flexibilidad tenemos o podremos tomar decisiones de diseño sabiendo que el backend no se va a tocar.

Imagina que como parte de un producto digital tienes un listado de artículos sobre los que puedes filtrar, ordenar y consultar el detalle de un producto al seleccionarlo. Lo lógico sería que antes de empezar a pensar en jerarquías, componentes y disposición de los elementos nos hagamos una serie de preguntas relacionadas con el contenido. Algunas de ellas podrían ser: ¿que datos tengo de cada producto en el listado? ¿y en el detalle? ¿en base a que campos puedo filtrar? ¿puedo realizar una búsqueda por texto?

Lo más frecuente es que estas y otras preguntas se puedan contestar viendo la documentación de la API. Supongamos que en nuestra API hay dos métodos que nos dan información para cubrir estas funcionalidades:

• El primero nos dará el listado de productos, con una información básica de cada uno de ellos, por ejemplo: id (único para cada producto, nombre y precio. Añadiendo información mediante parámetros podremos, además, filtrar y buscar usando las opciones que estén implementadas.
• El segundo nos dará toda la información de producto cuyo id le proporcionemos. Por ejemplo: imágenes, descripción, material del que está hecho y productos relacionados.

A partir de aquí podríamos plantear diferentes posibilidades, siempre alineados con el equipo de tecnología. Imagina, por ejemplo, que queremos mostrar en el listado una foto del producto. Echar un ojo a la documentación de la API nos revela que hasta que no «preguntemos» por un producto concreto no disponemos de ninguna foto. En este punto tendríamos varias opciones:

1. Para cada producto del listado, obtener la foto en la llamada que devuelve el detalle. Esto es una locura a nivel de rendimiento que probablemente provoque que el tiempo de carga sea muy superior al necesario, perjudicando la experiencia de usuario. No es una opción viable en el 99% de los casos.
2. Llegar a un acuerdo con el equipo de tecnología para modificar la respuesta del método con el que obtenemos el listado, haciendo que incluya también una foto del producto. Aquí cada caso es un mundo, habrá veces que lo que necesitamos implique un cambio mínimo mientras que otras será un desarrollo más complejo.
3. No mostrar la foto en el listado. Si tecnología no dispone de scope para realizar este cambio tendremos que plantearlo como una mejora a incluir en el futuro. En caso de que fuese algo imprescindible deberemos argumentar muy bien que implicaría no tenerlo, de cara a que el cliente o el equipo de producto puedan priorizarlo respecto a otras funcionalidades.

Mediante este ejemplo ilustramos el escenario más evidente en el que ser capaz de comprender cómo funciona la API nos puede ayudar a plantear un diseño «más realista» desde el principio. Por supuesto, a todas estas preguntas nos podría dar respuesta el equipo de tecnología, pero ser capaces de anticiparlas nos ayudará ser más eficaces y a evitar bloqueos en el día a día. Otros casos en los que la API nos puede ayudar a responder a algunas de nuestras preguntas podrían ser:

• Conocer el formato en el que la API devuelve un dato concreto, como una fecha. Si queremos cambiarlo tendremos que incorporar esa lógica en el frontend. Piensa que cada instrucción que se ejecuta suma tiempo a la carga de la vista o en la ejecución de una tarea, por lo que debemos ser cautos, especialmente cuando se ejecuten en bucle (por ejemplo en un listado, en el que se ejecuta la instrucción una vez por cada elemento del listado).
• Entender qué partes del producto pueden resultar algo más lentas de cargar por su complejidad y proponer soluciones de diseño para mejorar la experiencia. Por ejemplo, es bastante frecuente que para pintar un dashboard haya que hacer varias llamadas, y que la respuesta sea escalonada. Podemos plantear una estructura en la que el contenido se refleje a medida que se van recibiendo estas llamadas, o bien un skeleton que ayude al usuario a ir anticipando el contenido que podrá ver y esperar a tener todos los datos para mostrarlo. Especialmente en estos casos también es conveniente plantearnos si realmente todo lo que estamos mostrando es necesario, para no añadir tiempo de carga sin sentido.

¿Y cuando la API no es nuestra?

Para muchas de las funcionalidades que queramos implementar es probable que hagamos uso de APIs de terceros, siempre que estén disponibles para su uso público o mediante planes de pago. Por ejemplo, en la muchos de los productos en los que se muestran o hay interacción con mapas se usa la API de Google Maps.

Al integrar APIs de terceros estamos más limitados en cuanto a funcionalidad (si no queremos meternos en nuevos desarrollos sobre los métodos que ofrece la API), en cuanto a margen de cambios y muchas veces en el número de peticiones que podemos hacer (normalmente es una limitación cuando existen planes de pago).

A la hora de diseñar un producto que tendrá que integrarse si o si con una API de terceros es aun más importante estudiar previamente la documentación, ya que en la mayoría de los casos no podremos solicitar cambios al equipo de tecnología. Algunos productos con API pública como Slack han publicado su roadmap para dar pistas de lo que vendrá y animar a los usuarios a sugerir cambios y nuevos desarrollos.

Hackear las herramientas y «cacharrear»

Mas allá de un uso profesional, la existencia de APIs nos permite imaginar nuevos escenarios de uso y combinar las aplicaciones que usamos en nuestro día a día, dando lugar en ocasiones a nuevos productos.

Bien sea como forma de ahorrar tiempo, con fines divulgativos o por diversión, el abanico de posibilidades es tan amplio que muchas veces la limitación es nuestro propio conocimiento o tiempo. Sin embargo tener una idea en la cabeza y buscar la forma de hacerla realidad seguramente sea la mejor de las motivaciones para aprender. Te invito a que pienses como podrías dar una vuelta de tuerca a algo que uses a diario (y tenga API pública) y a averiguar si podrías hacerlo realidad.

Por mi parte, tengo en borradores un artículo en el que cuento cómo he conseguido que mi Thermomix me mande GIFs de Boris Izaguirre por Telegram. Además de un enchufe inteligente y algo de código, ha sido posible gracias a la API pública de Telegram, ¡a ver si lo termino y lo comparto!

Referencias y recursos para profundizar:

• https://www.xataka.com/basics/api-que-sirve
• https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces
• https://medium.com/@perrysetgo/what-exactly-is-an-api-69f36968a41f

---

Este es el primer artículo de la colección «APIs y Postman 4 Disainers«. Si quieres seguir aprendiendo sobre cómo entender la información en un JSON, te recomiendo echar un ojo al este artículo. También puedes ver algunos ejemplos de llamadas a APIs con Postman en este otro (pendiente de publicación).

¡Gracias por leerme! 🙂