5 preguntas que te ayudarán a definir la estrategia de tu API
Cada vez más las organizaciones y compañías se están viendo enfrentadas a la necesidad de hacer disponibles recursos, como información o servicios, que permitan a otros construir, por ejemplo, aplicaciones haciendo uso de dichos recursos de manera eficiente y rápida. La forma en la que estos recursos se han hecho disponibles ha sido, mayormente, a través de APIs.
Así como para las compañías, para los Product Managers esta creciente necesidad también se ha convertido en un reto. Y es que las APIs no son un concepto ñoño que sólo pueda y deba ser entendido por el equipo de ingeniería, al contrario, las APIs representan oportunidades de negocio que deben ser tratadas como productos que traen revenue o crecimiento para las organizaciones.
Para entender el valor de las APIs como estrategias de negocio, comencemos por lo básico.
¿Qué son las APIs?
De una forma sencilla, para que dos aplicaciones de software se puedan comunicar necesitan tener un lenguaje común y un mecanismo para lograrlo. Esencialmente, un API brinda estas capacidades a través de un contrato en el que se especifica el lugar en el que se pueden hacer llamadas a una biblioteca y las características que esas llamadas deben tener para que respondan de acuerdo a lo esperado.
Imaginemos que somos dueños de una biblioteca en la que tenemos ejemplares de cientos de libros. Cuando alguien quiere acceder a esos volúmenes debe llenar un formato de solicitud y debe entregarlo a nosotros para que, en respuesta, le entreguemos el libro que solicita. El lugar en el que esto ocurre es en la biblioteca, el formato de solicitud es el mecanismo por el cual la persona hace el requerimiento y los campos que llena son el lenguaje que nos ayuda a procesar esa solicitud y darle una respuesta. Esa respuesta que entregamos puede contener, a su vez, información relacionada como, por ejemplo, la fecha de expiración del préstamo, la información básica del libro y un código que identifique esa transacción.
Si ponemos esto en términos de APIs, el lugar en el que se hace la solicitud es comúnmente llamado un endpoint. En las APIs hay diferentes tipos de “formatos”. Imagina que en nuestra biblioteca existen formatos que nos permiten: saber si un libro está en el catálogo, solicitar el préstamo de un libro, retornar un libro que pedimos prestado y regalar un libro. Cada uno de estos usa un formato diferente que son identificados por colores, tienen nombres distintos y solicitan diferentes datos. De la misma forma, en las APIs tenemos métodos que nos permiten realizar diversas acciones, como traer información (GET
), agregar nueva información (POST
), cambiar información (UPDATE
), borrar información (DELETE
), etc.
La información que escribimos en estos formatos es lo que llamamos payload de entrada que es lo que le entregamos al API para que nos dé una respuesta. Esa respuesta también trae información que es entregada en un formato específico y que también llamaremos payload, pero esta vez, de salida.
Con esto claro, ahora veamos por qué deberíamos crear un API.
¿Cuál es el valor de negocio de esta API?
Fundamentalmente, una API es construida para hacer que cierta información sea disponible, ya sea internamente en una organización o externamente para los clientes u otros colaboradores.
La necesidad de construir un API puede venir de muchos lugares, como puede ser el crear una aplicación móvil, la capacidad de conectarse con un cliente o un proveedor, la necesidad de flexibilizar el consumo de la información que la organización ya tiene, escalar la integración clientes, etc. Pero, además de esto, la construcción de APIs, en la mayoría de los casos, ayuda a mejorar la arquitectura de los productos de una compañía porque la hacen más escalable y flexible cuando se trata de la interacción entre ellos.
Para definir este valor es básico entender cuál es objetivo de negocio que se quiere alcanzar con la construcción del API. Para esto, algunas preguntas que son útiles pueden incluir ¿qué se pretende lograr con el desarrollo de esta API?, ¿qué problema se pretende resolver?, ¿qué oportunidad se quiere aprovechar?. Las respuestas a estas preguntas pueden variar, pero idealmente, deberían guiarnos a entender cuál es el motivo que invita a la empresa a embarcarse en este proyecto.
Recuerda que las APIs hacen disponibles recursos y esos recursos deben responder a una necesidad. Por eso, es fundamental entender a quién le sirven esos recursos y por qué.
¿Cuál es el valor para el usuario?
La cadena de valor de un API comienza con quien posee recursos que son valiosos para alguien más. Esos recursos pueden ser información, servicios o productos que otras personas necesitan consumir. La función del API es hacer que esos recursos sean disponibles para esas personas. Sin embargo, a diferencia de otros productos, los recursos que se disponibilizan a través de un API tienen tres tipos de consumidores: por un lado, se encuentran los desarrolladores que acceden a esos recursos y los usan para construir otras aplicaciones, las aplicaciones que los consumen y finalmente, los usuarios finales de dichas aplicaciones.
El primer paso para determinar el beneficio para el usuario es, sin duda, ser capaces de estimar el verdadero valor de los recursos que tenemos para hacer disponibles. Si los desarrolladores no encuentran valor en dichos recursos, nuestra API, como producto, estaría destinada a fracasar. Para evitar esto, es importante entender qué problema resuelve el API y cómo mejora lo que sea que ya es consumido en este momento.
Fuente: https://thenewtechnicalwriter.wordpress.com/2015/08/10/understanding-the-api-value-chain/
Con esto en mente, cuando queremos construir un API debemos considerar todos estos involucrados en el proceso, y entender cuáles son las motivaciones que trae a cada uno a participar en esta cadena de valor. Estas consideraciones nos informan sobre los niveles de necesidades a los que nos estamos enfrentando y a anticiparnos en el diseño del API para responder a ellas.
¿Cómo hacer estos recursos disponibles?
Con una validación concreta de la oportunidad de negocio, el siguiente paso es entender cómo podemos hacer estos recursos disponibles. En esta área las discusiones pueden ser interminables, los diferentes miembros del equipo involucrado seguramente darán sugerencias sobre cómo se debe ejecutar la solución. Sin embargo, la responsabilidad del Product Manager, más allá de definir tecnologías, es la de proporcionar al equipo de ingeniería la suficiente información que les permita definir una solución que se ajuste a las necesidades de los usuarios y las condiciones actuales del negocio.
De la misma forma en la que trabajamos con los equipos de diseño de producto, debemos trabajar con ingeniería para entregarles a ellos el contexto que les permita diseñar soluciones valiosas. Las soluciones que los ingenieros propongan estarán influenciadas por el stack que se usa dentro de la compañía, así como las prácticas ya establecidas en la organización y las necesidades específicas que propone el problema.
Aunque no es decisión del Product Manager tomar estas decisiones, sí es importante que esta persona sea capaz de entender el por qué se toman las decisiones que se toman con respecto a tecnologías y diseño. ¿Qué se busca lograr con lo que se propone?, ¿por qué esta propuesta y no otra?, ¿qué beneficios trae este diseño a la organización y al cliente?. Estas preguntas ayudan a que el PM tenga suficiente contexto de la solución, entienda claramente el valor que estas decisiones traen para el usuario y sea capaz de comunicar esta información a los stakeholders.
¿Qué objeciones pueden surgir?
Si bien las APIs son soluciones ideales en muchos casos, siempre vamos a encontrarnos con cuestionamientos provenientes de diferentes áreas. Los stakeholders del proyecto pueden no hallar suficiente valor en un API si se están haciendo disponibles recursos internos para consumidores internos. De la misma forma, el equipo de seguridad puede identificar riesgos al hacer disponibles recursos de manera pública.
Una preocupación constante que surge en las discusiones sobre la construcción de APIs es el impacto que tiene esa construcción en los tiempos de carga y respuesta de los sistemas. Es siempre una buena idea considerar esta inquietud y discutirla con los ingenieros, de manera que haya claridad sobre este impacto y cómo esto puede afectar a los diferentes usuarios del producto.
Así como estas, pueden existir múltiples objeciones a la construcción de un determinado API. Aquí nuestra responsabilidad es identificarlos y darles respuesta. No siempre podremos solucionarlos todos, pero sí debemos ser responsables de generar una comunicación clara sobre los impactos del proyecto y cómo se planea mitigarlos.
¿Cómo manejar la seguridad del API?
La seguridad de una API debe ser parte de las discusiones sobre su diseño e implementación. En general, estas discusiones están basadas en el tipo de recurso que se está haciendo disponible, esto quiere decir que dependiendo de las sensibilidad de la información serán las medidas de seguridad que se deban implementar para asegurarla.
En este sentido, esa es la primera pregunta que debemos hacer: ¿qué información estamos publicando y cuál es su nivel de sensibilidad?. Imaginemos que tenemos un conjunto de datos sobre las obras de millones de autores. La información es conocida públicamente y su distribución no pone en riesgo a sus dueños, ni a ningún involucrado, por eso, podemos hacerla disponible con medidas de seguridad no tan complejas. Sin embargo, si estamos hablando de información delicada como datos de identificación, nuestra aproximación al problema sería diferente.
Si la información que estamos haciendo disponible enfrenta vulnerabilidades, entonces, nuestra decisión será, muy probablemente, implementar mecanismos de seguridad que nos ayuden a resguardar los datos. Sin embargo, estas implementaciones pueden generar impactos en los tiempos de respuesta o acceso a la información.
De la misma forma, debemos considerar quiénes tienen acceso a la información y en qué medida. Puede darse el caso en el que tengamos que implementar mecanismos de identificación, autenticación y autorización para permitir el acceso a ciertos datos o a ciertas acciones dentro del API.
Estas son sólo algunas de las preguntas que nos podemos hacer cuando estemos definiendo la estrategia de un API. Considerar estos cuestionamientos puede hacer que nuestro trabajo sea más eficiente y efectivo cuando se trata de conseguir una solución que traiga valor para los usuarios. Al final, un API es una interfaz, un producto.