Las 8 claves para alcanzar un buen Gobierno de APIs

Serie API Owner Fundamentals

Algunos de nuestros warrior acudieron al curso de API Owner promovido por la Fundación APIAddicts de la que somos sponsors desde hace más de 6 años. Para compartir la visión global y el conocimiento que han adquirido han realizado una serie de blogs muy interesantes para entender todo el proceso de APIficación.

Para empezar, el gobierno de APIs surge de la necesidad de estandarizar y homogeneizar los procesos, metodologías y prácticas relacionados con las APIs dentro de una organización. Este engloba todas las fases desde la definición a la publicación pasando por el desarrollo e implementación, entre otras.

La mayoría de acciones y procedimientos que se pueden realizar para alcanzar un buen gobierno de APIs se pueden agrupar en ocho bloques, y de eso es lo que vamos a hablar hoy.

1. API bien definida

La organización debe de contar con un estándar de definición. Este estándar debe de dejar muy claro que está permitido y que no está permitido a la hora de definir un API. Además este estándar debe de marcar las pautas para definir de forma homogénea cada uno de los distintos componentes (reglas que deben aplicar sobre las urls, estructuras de respuesta, códigos de estado, formatos de datos, etc). Este estándar debe ser agnóstico para luego poder aplicarse a distintos estándares de definición (por ejemplo OpenAPI).

Además se recomienda que la organización tenga una o varias plantillas donde ya estén definidos los aspectos comunes a todas las APIs.

2. API segura

A la hora de definir una API hay que definir también qué criterios de seguridad deberá de cumplir. Estos criterios generalmente serán respecto a cumplir estándares de seguridad (OWASP) como de tener cierta capa de seguridad por encima del API (rate limiting, antiataque, etc).

Habrá criterios de seguridad que serán comunes en todas las APIs de la organización (por ejemplo revisar que no hay errores OWASP) y otras que serás específicas del API (por ejemplo tener cierto control de acceso) o incluso de un endpoint en concreto (por ejemplo tener un límite de X llamadas por hora al endpoint de restablecer contraseña).

3. API bien probada

La implementación de una API debe de tener cierto nivel de calidad. Este nivel se puede comprobar de múltiples formas.

Pruebas manuales

Sirven al desarrollador para validar que el código que está realizando es correcto. Generalmente sólo cubren el happy path y al ser manuales no se repiten debido al gran coste de tiempo que implican.

Análisis de código

Sirve para detectar tanto problemas de diseño en el código como errores respecto al uso de métodos o librerías. Generalmente sirven para encauzar el código hacia un estado más limpio y detectar ciertos bugs de rendimiento o condicionalidad (ej: no cerrar streams).

Test unitarios

Estos nos permiten validar que las piezas individuales de nuestro código realizan el comportamiento esperado. Generalmente sirven para detectar bugs de la lógica de negocio individual.

Test de integración o e2e

Estos nos permiten validar que los endpoints presentan el comportamiento esperado así como poder definir tests que impliquen un flujo de usuario, pudiendo así validar la interacción de múltiples endpoints. Generalmente son un buen indicador para detectar si ciertos cambios en el API han causado problemas en otras partes de esta.

4. API homogéneas a nivel de organización

No sirve de mucho tener definida una API donde todos los recursos tengan una definición homogénea si en otra API los mismos recursos tienen cualidades distintas (a nivel de nombre, atributos, tipos, etc). En este punto entra en juego el diccionario de recursos a nivel de la organización. Este contendrá las definiciones estándar para recursos comunes que sean utilizados en las definiciones de múltiples APIs. Esto permite simplificar la definición de las APIs al poder reutilizar recursos y simplifica el consumo de dichas APIs ya que el consumidor no tendrá inconsistencias si está consumiendo múltiples APIs en un mismo punto.

5. API bien gobernada

Nuestra API debe de tener distintos entornos. Cada entorno aporta un valor distinto en la cadena de desarrollo del API.

Desde el entorno de desarrollo donde se van integrando las funcionalidades, pasando por el entorno de staging donde se comprueba la estabilidad hasta llegar al entorno de producción. Además es muy recomendable disponer de un entorno de sandbox al menos si se trata de una API que será utilizada por terceros.

La correcta gestión de dichos entornos también se incluye en este punto. Desde tener en todo momento controladas las similitudes y diferencias entre ellas hasta saber dónde se deben de publicar, etc.

6. Procesos y roles

Uno de los procesos importantes a tener en cuenta en una API es la gestión de su ciclo de vida. En este aspecto se debe definir la estrategia seguir respecto a nuevas versiones, tiempo de vida del api, notificaciones de actualización de api, etc.

Respecto a los roles hay que tener claro quién va a ser el API Owner, App Developer, API Developer, API Tester, DevOps y Operations Team.

7. Monitorización

La monitorización es una de las partes más importantes a tener en cuenta en una API que está en producción. Esto puede marcar una gran diferencia en el tiempo de detección de anomalías relacionadas con nuestra API.

La monitorización incluye un espectro bastante amplio de distintos componentes o piezas entre las cuales destacan:

Endpoints de status

Indican la salud de nuestra API, su granularidad puede variar desde ser un único flag de OK/KO hasta tener información específica del estado de cada componente que utiliza nuestra API (ej: estado de la conexión con la BD, cache, etc)

Gestión de logs

La correcta gestión de logs dentro de un API es un aspecto crítico que dependiendo de si se hace de forma correcta o incorrecta puede suponer una gran diferencia a la hora de investigar causas de anomalías. Por ello es importante que nuestra API utilice de forma correcta el log (indicando el nivel correcto en cada sentencia y proporcionando la información de contexto adecuada)

Log Server

Permite montar cuadros de mando nutridos a partir de los logs de nuestras APIs. Sirve para que podamos visualizar de forma sencilla el estado de estas así como las métricas de cada una de ellas.

Alarmas

No sirve de mucho tener mucha información si luego no se hace uso de ella. Las alarmas o notificaciones nos sirven para reaccionar rápido ante ciertos eventos que se detecten. Por ejemplo recibir un email si hay X errores 500 en una hora, etc. Este es el componente principal que nos ayuda a reaccionar lo antes posible ante las anomalías.

8. Catalogación

Si hay muy pocas APIs no vamos a tener muchos problemas en recordar cuales son, pero conforme su número aumente necesitamos servirnos de herramientas para poder tener un control sobre estas. Un API Portal nos permite tener definidas y catalogadas las APIs.

Conclusiones

Las APIs juegan un papel crucial en la transformación digital. La elaboración de una estrategia de APIs es compleja y debe estar supervisada durante su diseño y ejecución para garantizar su buen funcionamiento. Para ello, es necesario implementar correctamente un Gobierno de APIs que permita estandarizar y homogeneizar los procesos de APIficación dentro de nuestra empresa u organización.

Próximo blog de la serie API Owner - API Definition

Blog realizado por Adrián Palanques

Backend Developer .NET (Castellón)

¡No te pierdas el próximo capítulo!

Suscríbete al blog de los warriors

Subscribirme ya

Cómo definir correctamente mi API Template

API Governance

administración CloudAPPi