Las API y los puntos finales siempre han sido un tema de debate candente entre los desarrolladores de frontend y backend por igual. Para desarrollar aplicaciones y servicios útiles y sostenibles, las API han sido poderosos medios y facilitadores.

Las API facilitan la transmisión de datos entre varios artefactos de software para resolver los problemas de los clientes. Casi todos los productos modernos basados en la web ofrecen sus propias API para interactuar e integrar sus servicios directamente en cualquier proyecto.

Para estar a la altura de tus competidores y ofrecer a tus usuarios una experiencia fluida en todas las plataformas, tienes que conocer y dominar el juego de las API.

Esta guía desglosará el término y te ayudará a saber qué es un punto final de API, cómo puedes consumir una API disponible públicamente y las distintas formas de asegurar y supervisar tus puntos finales de API.

Entender los Puntos Finales de la API

«API» es la abreviatura de «interfaz de programación de aplicaciones». Es esencialmente un conjunto de reglas que permiten a una aplicación compartir sus datos con otras aplicaciones. En palabras sencillas, una API te permitirá «compartir cosas» entre tu aplicación y una aplicación de terceros.

Un punto final de la API es una ubicación digital expuesta a través de la API desde la que esta recibe solicitudes y envía respuestas. Cada punto final es una URL (Localizador Uniforme de Recursos) que proporciona la ubicación de un recurso en el servidor de la API.

Para entender la finalidad y el uso de las API, entendamos primero cómo funcionan.

Cómo Funcionan las API

Para que dos aplicaciones de software se comuniquen a través de Internet, una aplicación (denominada cliente) envía una solicitud a los puntos finales de la API de la otra aplicación (denominada servidor). Dependiendo de las capacidades de la API, el cliente puede solicitar un recurso de una base de datos o pedir al servidor que realice alguna acción en su entorno y le devuelva los resultados.

Al recibir el resultado del cliente, la API (o el servidor) ejecuta la operación solicitada y devuelve el resultado de la operación al cliente en forma de respuesta. Esta respuesta también puede incluir cualquier recurso que el cliente haya solicitado.

Puede haber varios tipos de API, como REST, SOAP y GraphQL. Todas funcionan de manera diferente, pero su objetivo sigue siendo el mismo: facilitar la comunicación entre entidades basadas en la web. En esta guía, hablaremos principalmente de las API REST, ya que están entre las más populares a nivel mundial.

¿Cuál es la Diferencia Entre una API y un Punto Final?

Esto nos lleva a la siguiente y más común pregunta: ¿Cuál es la diferencia entre una API y un punto final?

Una API es un conjunto de protocolos y herramientas para facilitar la interacción entre dos aplicaciones. Un punto final es un lugar de la API donde se produce el intercambio. Los puntos finales son URI (Identificadores Uniformes de Recursos) en una API a los que una aplicación puede acceder.

Todas las API tienen puntos finales. Sin un punto final, sería imposible interactuar con una API.

¿Cómo Funcionan los Puntos Finales con las API?

Para que entiendas mejor lo que son las API y los puntos finales, vamos a poner un pequeño ejemplo.

Piensa en la API de Cat Facts. Esta API proporciona datos aleatorios sobre los gatos. Sin embargo, enumera varios puntos finales con los que puedes solicitar información categorizada. Hay tres puntos finales disponibles:

  • /fact: Devuelve un único dato aleatorio sobre el gato.
  • /facts: Devuelve una lista de datos aleatorios sobre gatos.
  • /breeds: Devuelve una lista de razas de gatos.

Para hacer una solicitud a esta API y recuperar un dato sobre gatos, tienes que añadir el punto final correcto (que es /fact) a la URL base de la API (que es https://catfact.ninja/). Esto te dará la siguiente URL del punto final: https://catfact.ninja/fact

Si envías una solicitud GET a la URL anterior, recibirás un resultado similar:


{
    "fact": "Spanish-Jewish folklore recounts that Adam\u2019s first wife, Lilith, became a black vampire cat, sucking the blood from sleeping babies. This may be the root of the superstition that a cat will smother a sleeping baby or suck out the child\u2019s breath.",
    "length": 245
}

Ahora bien, no habrías podido obtener estos datos si hubieras accedido a otro endpoint, como /breeds. Así es como los puntos finales ayudan a interactuar y organizar los recursos proporcionados por una API: cada punto final es específico para una parte concreta de los datos.

¿Por qué son Importantes los Puntos Finales de la API?

La transferencia de datos y el intercambio de recursos son algunas de las bases fundamentales de Internet. Cada día se añaden más procesos y aplicaciones a la red global, lo que añade valor a la red al compartir cosas.

Sin las API, nada de esto sería posible. Las API proporcionan un poderoso medio de comunicación e interacción entre las aplicaciones basadas en la web.

Los puntos finales de las API, a su vez, ayudan a determinar la ubicación exacta de los recursos en la API. Ayudan a los desarrolladores de la API a organizar los recursos disponibles y también a controlar el acceso de los consumidores. Por tanto, el rendimiento y la productividad de las aplicaciones que consumen API dependen directamente del diseño y el rendimiento de los puntos finales de la API.

Trabajar con los Puntos Finales de la API Existentes

En la mayoría de los casos, tendrás que consumir API pre construidas. Para hacerlo de forma eficiente, tienes que entender cómo localizar los puntos finales y orientarte con las distintas reglas de versionado que se utilizan en el sector. Esta sección te guiará por ellas.

Localizar un Punto Final de la API

Localizar un punto final de la API es una tarea sencilla si tienes acceso a la documentación de la API. A veces, la documentación puede enumerar los puntos finales simplemente con breves descripciones junto a cada uno de ellos. En otros casos (como el de Swagger), la documentación puede ser más compleja y potente, y puedes probar los puntos finales directamente desde la página de documentación.

En cualquier caso, te conviene dedicar tiempo a comprender la finalidad de cada punto final antes de empezar a utilizarlo. Esto puede ayudarte a evitar la mayoría de los errores y a mejorar tu eficacia.

Versionado de los Puntos Finales de la API

Como la mayoría de los demás artefactos de software, las API también están versionadas. El versionado ayuda a observar y analizar la API a medida que crece a través del proceso de desarrollo. Tener acceso a las versiones antiguas también puede ayudarte a retroceder a versiones anteriores y estables en caso de una actualización defectuosa. Estas son algunas de las formas más comunes de versionar los puntos finales de la API.

Ruta URI

Una de las formas más populares de versionar los puntos finales de la API es incluir un número de versión en la ruta URI. Este es el aspecto que podría tener:

http://example.com/api/1/resourcename

Puedes ver este enfoque como una manera de versionar globalmente los puntos finales de la API. Si utilizas un subdominio para tu API, como:

http://api.example.com/resourcename

… También puedes poner un indicador de versión en tu subdominio, así:

http://api-v2.example.com/resourcename

Como puedes ver, este enfoque modifica la ruta URI de la API, de modo que cada versión se comporta como un recurso independiente en sí mismo. Esto significa que puedes acceder simultáneamente a las dos versiones de la API según sea necesario e incluso almacenarlas en caché de forma independiente para un acceso más rápido.

Si incluyes un número de versión en la ruta URI (y no en el subdominio), aquí tienes un formato claro que puedes seguir para incluir más información:

MAJOR.MINOR.PATCH

Por ejemplo, así es como se versionaría la API interna de nuestro ejemplo anterior:

http://example.com/api/1.2.3/resourcename

Ahora, vamos a desglosar estos nuevos términos de versión y para qué sirve cada uno:

  • MAJOR: Para cuando hagas cambios incompatibles o que rompan la API
  • MINOR: Para añadir funcionalidad compatible con versiones anteriores
  • PATCH: Para corregir errores compatibles con las versiones anteriores

La versión MAJOR es la versión utilizada en la API pública. Este número suele actualizarse cuando se realiza un cambio importante o de ruptura en la API. Internamente, un cambio de este tipo indica que se ha creado una nueva instancia o recurso de la API por completo.

Las versiones MINOR y PATCH se utilizan internamente para actualizaciones de compatibilidad con versiones anteriores. Suelen actualizarse cuando se introduce una nueva funcionalidad, o cuando se ejecutan cambios menores en el mismo recurso de la API. El número PATCH se actualiza específicamente para corregir errores o resolver problemas.

  • Beneficios:
    • Es posible el acceso simultáneo a varias versiones.
    • La denominación de las URL sigue una convención sencilla y estándar, de modo que los puntos finales de la API son muy accesibles.
  • Limitaciones:
    • En el caso de los cambios de ruptura, este enfoque conduce al desarrollo de un nuevo recurso de la API en su totalidad. Esto puede añadir un peso significativo a tu código base.
Parámetros de Consulta

Otra alternativa para versionar una API REST es poner el número de versión en los parámetros de consulta de su URL. Esto permite al entorno del servidor acceder al número de versión requerido como cualquier otro parámetro de consulta y utilizarlo para redirigir el flujo de control en la aplicación. No es necesario que crees un nuevo recurso de la API, ya que tu recurso de la API existente puede leer el número de versión y actuar en consecuencia.

Este es el aspecto de la URL del ejemplo anterior cuando se versiona utilizando parámetros de consulta:

http://example.com/api/resourcename?version=1
  • Beneficios:
    • Muy fácil de implementar en el código.
    • Puedes pasar rápidamente a la última versión por defecto.
  • Limitaciones:
    • Los parámetros pueden ser más difíciles de usar para dirigir las peticiones a la versión correcta que el versionado de la ruta URI.
Cabeceras Personalizadas

También puedes versionar las API REST suministrando cabeceras personalizadas con el número de versión como atributo. La diferencia más significativa entre este método y los dos mencionados anteriormente es que este no abarrota la URL del punto final con información sobre la versión.

Así es como se vería el ejemplo de antes cuando se versiona utilizando este método:

curl -H "Accepts-version: 2.0"

http://example.com/api/resourcename
  • Beneficios:
    • La URL no está abarrotada de información sobre la versión.
    • Los clientes pueden codificar las URL de los puntos finales de la API y elegir entre las versiones a través de las cabeceras mientras envían la solicitud rápidamente.
  • Limitaciones:
    • Tienes que establecer manualmente las cabeceras personalizadas cada vez que hagas una petición.
Negociación del Contenido

La negociación del contenido permite a los desarrolladores de la API versionar una única representación del recurso en lugar de toda la API. Esto les da un control más granular sobre el versionado. Al igual que el anterior, este método también elimina el desorden de las URL de la API.

Este es el aspecto de nuestro ejemplo anterior cuando se versiona a través de la negociación de contenido:

curl -H "Accept: application/vnd.kb.api+json; version=2"

http://example.com/api/resourcename

Sin embargo, los puntos finales versionados con este método son más difíciles de acceder que los que se han hecho con el método URI. Además, el uso de cabeceras HTTP con tipos de medios hace que sea difícil probar la API en un navegador. Y si la cabecera de contenido es opcional, puede causar confusión sobre qué versión recibirán los clientes por defecto.

Supongamos que has lanzado una v2 para tu API y has dejado obsoleta la versión anterior v1. Si un cliente no especifica la versión en su solicitud, recibirá el recurso v2, lo que podría romper su funcionalidad debido a problemas de compatibilidad no contabilizados. Por eso, la negociación de contenidos no suele recomendarse como medio de versionado de la API

  • Beneficios:
    • Puedes versionar un solo recurso si es necesario.
    • Crea una huella de código más pequeña.
    • No requiere que modifiques las reglas de enrutamiento (URL).
  • Limitaciones:
    • Las cabeceras HTTP con tipos de medios dificultan las pruebas y la exploración de los puntos finales en un navegador.
    • Ten en cuenta, además, que la falta de cabecera de contenido puede romper la funcionalidad del cliente.

Ejemplo de un Punto Final de la API

Para entender mejor las API y los puntos finales, ilustraremos un ejemplo utilizando la API de Twitter. Esta API expone datos sobre tweets, mensajes directos, usuarios y más de la plataforma de medios sociales. Ofrece varios puntos finales para realizar diversas operaciones sobre sus datos.

Por ejemplo, puedes utilizar el punto final de búsqueda de tweets (https://api.twitter.com/2/tweets/{id}) para recuperar el contenido de un tweet específico utilizando su identificador único. También puedes utilizar la API de Twitter para transmitir tweets públicos en tiempo real a tu aplicación web para mantener a tus usuarios informados sobre un tema de interés concreto.

La API de Twitter ofrece un punto final de flujo filtrado para este fin (https://api.twitter.com/2/tweets/search/stream). También han creado un índice ampliado de otros puntos finales que puedes utilizar.

¿Cómo Están Protegidos los Puntos Finales de la API?

Ahora que entiendes el aspecto y el funcionamiento de un punto final de la API, es crucial saber cómo asegurarlo. Sin las medidas de seguridad adecuadas, un punto final de la API puede ser una grieta importante en la armadura de tu aplicación, lo que podría conducir a la violación de datos y recursos.

He aquí algunas sugerencias básicas para asegurar el acceso a tus puntos finales de la API.

Hashing de Contraseñas en un Solo Sentido

Al construir recursos web, a menudo te encontrarás con contraseñas como forma de autenticar entidades. Aunque las contraseñas ayudan a asegurar los datos de tus usuarios en la aplicación, necesitas asegurar también el almacenamiento de las contraseñas para que sean un medio de autenticación realmente eficaz.

En general, nunca debes almacenar las contraseñas como texto plano. En caso de que se produzca una brecha de seguridad, todas las cuentas de usuario se verán comprometidas si un mal actor pone sus manos en la tabla de pares de cadenas de nombre de usuario y contraseña.

Una forma de evitarlo es cifrarlas antes de almacenarlas. Hay dos métodos de cifrado: simétrico y asimétrico.

En el cifrado simétrico, puedes utilizar la misma clave de cifrado para bloquear y desbloquear el contenido. Sin embargo, esto no es aconsejable para las contraseñas, ya que los hackers persistentes y sofisticados pueden romperlas fácilmente.

La forma recomendada de almacenar las contraseñas es utilizar un cifrado unidireccional o «asimétrico». En lugar de emplear una única clave de cifrado, se utiliza una función matemática para codificar los datos.

La versión codificada se almacena en la base de datos para que nadie, incluidos los administradores del servidor, pueda descifrar las contraseñas y verlas. Para autenticar a los usuarios, la contraseña introducida se somete a la misma función matemática, y los resultados se comparan para comprobar si la contraseña introducida es correcta.

HTTPS

Supón que tus puntos finales de la API están diseñados para permitir a los consumidores hablar con tus servicios. En ese caso, los pondrás en un riesgo importante si no implementas HTTPS (u otro protocolo de seguridad similar).

Las conexiones de la API suelen intercambiar datos sensibles, como contraseñas, claves secretas e información de pago. Estos datos pueden ser fácilmente robados por un ataque de máquina en el medio o a través de métodos de rastreo de paquetes.

Por ello, debes elegir siempre HTTPS cuando esté disponible. Si tus aplicaciones utilizan actualmente el protocolo HTTP, deberías considerar seriamente la posibilidad de migrar a HTTPS. No importa lo insignificante que sea la conexión; siempre puede dar lugar a una filtración.

También deberías considerar la posibilidad de adquirir un certificado TLS o SSL para mejorar aún más la seguridad de tu API.

Limitación de la Tasa

En la mayoría de los casos, establecer un límite en el número de veces que se puede utilizar tu API en un minuto es una buena idea. Te ayuda a controlar cualquier uso indebido de los recursos y a introducir un modelo de precios gestionado en función de tu tráfico de consumidores.

Sin embargo, una de las principales razones para implementar la limitación de la tasa es evitar el uso excesivo de los recursos de forma automatizada, que suele ser gracias a los bots que pueden enviar cientos o miles de peticiones simultáneas cada segundo. La limitación de tasas también puede ayudarte a bloquear cualquier ataque DDoS lanzado por estos bots.

La mayoría de los frameworks de desarrollo web proporcionan middlewares de limitación de velocidad listos para usar y fáciles de configurar. Incluso si tu framework no tiene un middleware, puedes conseguir uno a través de una biblioteca de terceros y configurarlo con bastante rapidez.

Aparte de vigilar los bots, también es una buena práctica limitar el número permitido de peticiones o datos recuperados a un número razonable. Hacerlo ayuda a evitar el sobreuso involuntario de los recursos que puede desencadenarse a través de errores manuales como los bucles infinitos. También ayuda a proporcionar a tus usuarios una disponibilidad uniforme: un pico en el uso de un usuario no afecta a la experiencia de otros usuarios.

Medidas de Autentificación de la API

Siempre que construyas una API de cara al público, debes implementar medidas de autenticación para evitar el mal uso y el abuso de tus servicios. Una buena opción es el sistema OAuth2.

El sistema OAuth2 divide tu cuenta en recursos y te permite proporcionar un acceso controlado a los portadores de tokens de autenticación. Puedes configurar estos tokens para que caduquen en periodos de tiempo determinados -por ejemplo, 24 horas-, tras los cuales se refrescarán. Esto asegura que incluso si tu token se filtra, la ventana de uso limitado reducirá el impacto de la filtración.

Una parte esencial de la seguridad de la API es el uso de claves de la API para autenticar las solicitudes. Puedes establecer claves de API para limitar la tasa de llamadas a tu API y reducir las posibilidades de ataques DoS. Si ofreces un servicio de API de pago, puedes utilizar claves de API para proporcionar acceso en función de los planes que haya contratado cada usuario.

También deberías considerar la posibilidad de dotar a los puntos finales de tus empleados internos de autenticación multifactor, software antivirus y actualizaciones automáticas de las aplicaciones. Estas sencillas medidas contribuirán en gran medida a garantizar que no se produzca una brecha en la calidad de los servicios que ofreces.

Validación de Entradas

Aunque esto parece algo obvio al construir cualquier aplicación de software, un número sorprendente de API no lo implementan adecuadamente. La validación de la entrada no solo consiste en comprobar que los datos entrantes tienen un formato correcto, sino también en evitar sorpresas.

Uno de los ejemplos más sencillos, pero más comunes, es la inyección SQL. No cubrir esto puede acabar con toda tu base de datos si se ejecuta la consulta incorrecta. Asegúrate de validar los datos de entrada para que tengan el formato adecuado y elimina los caracteres que puedan mostrar una intención maliciosa.

Otro aspecto a tener en cuenta es el tamaño de la solicitud. En el caso de las peticiones POST, intentar aceptar y analizar una entrada extremadamente grande solamente hará que tu API se desborde. Siempre debes centrarte en validar primero el tamaño de una solicitud POST y devolver un código de error y un mensaje adecuados al cliente, si procede.

Filtrado de Direcciones IP

Si ofreces servicios B2B y tus clientes utilizan tu API desde determinadas ubicaciones a nivel mundial, deberías considerar la posibilidad de añadir una capa adicional de seguridad a tus sistemas restringiendo las direcciones IP que acceden a tu API, en función de su ubicación.

Para nuevas ubicaciones y clientes, tendrás que añadir sus datos a tu lista de «ubicaciones permitidas». Aunque esto puede añadir una fricción adicional al proceso de incorporación de tus clientes, contribuirá en gran medida a mejorar la seguridad y, a su vez, la calidad de su experiencia.

Para minimizar aún más los riesgos de seguridad, también deberías considerar la posibilidad de limitar los permisos y el acceso de los clientes al mínimo necesario para las operaciones estándar. Del mismo modo, restringe el acceso HTTP para garantizar que los clientes mal configurados no reciban más que las especificaciones de la API y el código de acceso. Asegúrate de que tu API rechaza estas peticiones con un código de respuesta 405.

Vale la pena señalar que una gran parte de los ciberataques en el mundo se originan en un número limitado de países. Otra buena práctica es bloquear totalmente el acceso a tus recursos desde esos lugares si no tienes clientes allí.

Además, si detectas un ataque, empieza por bloquear las peticiones GET/POST de la región del atacante. La capacidad de restringir las peticiones HTTP en función de la ubicación de los clientes es una de las formas más rápidas de contrarrestar un ciberataque en curso.

XDR (Detección y Respuesta Ampliada)

La mayoría de las organizaciones despliegan herramientas de seguridad tradicionales, como cortafuegos y técnicas de protección/detección de intrusiones. Aunque estas son rudimentarias para cualquier sistema de seguridad, no están diseñadas explícitamente para las API.

Una nueva tecnología llamada XDR proporciona un enfoque mejor y más holístico de la protección en todos tus entornos de TI, incluidos tus puntos finales de API. XDR proporciona a los equipos de seguridad alertas en tiempo real sobre comportamientos maliciosos, lo que les permite investigar los ataques rápidamente.

Estas son algunas de las formas en que la XDR protege los puntos finales de las API:

  • Supervisión de HTTPS: XDR puede gestionar los certificados de seguridad de tus puntos finales e inspeccionar también las comunicaciones HTTP. Cuando detecta una anomalía, puede terminar rápidamente la conexión o tomar otra acción automatizada.
  • Monitorización de llamadas a la API: XDR puede hacer un seguimiento del número de llamadas a la API realizadas por tus clientes y notificar a tus equipos de seguridad cuando detecte tendencias sospechosas, incluso dentro de los límites de velocidad establecidos.
  • Token web JSON (JWT): El JWT es un método estándar utilizado para representar de forma segura la identidad de un usuario cuando se comunica a través de una red. La XDR puede ayudar a identificar a los usuarios a través de JWT en tus redes sin tener que transmitir credenciales. Esto te permite identificar las cuentas de usuario en tu tráfico de la API y analizar su comportamiento en busca de anomalías.
  • Filtrado de direcciones IP: El XDR se integra bien con las bases de datos de inteligencia de amenazas y comprueba las solicitudes entrantes para ver si hay direcciones IP u orígenes legítimos.
  • Validación de entradas: Incluso si no has implementado medidas adecuadas de sanitización de entrada en tu servicio, las soluciones XDR pueden analizar automáticamente las consultas SQL o de otro tipo sensibles a la base de datos para detectar ataques de inyección, detenerlos en seco y notificar a los equipos de seguridad sobre ellos.

Rutinas de Mantenimiento

Hay algunas rutinas de mantenimiento generales que puedes establecer para mejorar la calidad de la seguridad de tus API. Aquí tienes algunas de ellas:

  • Limpia los datos: Elimina los datos redundantes de usuarios y empleados de tus servicios. La limpieza rutinaria de datos no solo es una buena práctica, sino que también ayuda a disminuir las posibilidades de pérdida o corrupción accidental de datos.
  • Realiza actualizaciones periódicas: Recuerda actualizar regularmente tu pila tecnológica y las certificaciones de los servicios. Debes aplicar parches rutinarios para tus servicios de punto final, y todas tus licencias deben reflejar las últimas normas de regulación y cumplimiento.
  • Revisa las medidas de seguridad: Mantén al día tus planes de seguridad y recuperación. Deben reflejar los últimos cambios o adiciones a tu infraestructura de red con la mayor frecuencia posible. Si añades regularmente nuevos recursos móviles, de IoT o de otro tipo en las instalaciones, esta práctica es aún más crítica.

Supervisión de los Puntos Finales de la API

Ahora que entiendes cómo construir, consumir y asegurar los puntos finales de la API, lo siguiente esencial que debes saber es monitorizarlos. La monitorización es un concepto crucial que se aplica en toda la dinámica de la ingeniería de software para analizar y reforzar el crecimiento de los productos técnicos.

Consejos, Trucos y Buenas Prácticas

En el caso de los puntos finales de la API, la monitorización puede ayudarte a asegurar y optimizar tus puntos finales para mejorar el rendimiento y la fiabilidad. La siguiente sección te guiará por algunas de las mejores prácticas que debes seguir al instrumentar y supervisar los puntos finales de la API.

1. Validar el Tiempo de Funcionamiento

Por lo general, los equipos tienden a supervisar la disponibilidad de la API o el tiempo de funcionamiento y lo consideran el estándar para medir la calidad del servicio de la API. Sin embargo, medir solo la disponibilidad general de la API no es suficiente para los distintos tipos de transacciones de intercambio de datos que se producen a través de la API. Tienes que supervisar la disponibilidad y el rendimiento de todos los verbos (Crear, Leer, Actualizar, Eliminar, etc.) individualmente para asegurarte de que todos están operativos.

Para ello, puedes implementar herramientas de supervisión sintética con monitores de API de varios pasos. Esto te ayudará a mejorar la disponibilidad de la API y de los datos simultáneamente. Al mismo tiempo, debes recordar que la supervisión sintética utiliza un conjunto limitado y predefinido de llamadas a la API para las pruebas. Por tanto, el tráfico real puede diferir del conjunto de entradas en la monitorización sintética.

2. Recuerda Supervisar las Dependencias de la API

No todas las API se construyen de forma independiente. Lo más frecuente es que tengas que consumir API de terceros mientras construyes la tuya propia. Y aunque puedes instrumentar tu código hasta sus niveles más profundos, puedes olvidar fácilmente el seguimiento del comportamiento de esas API de terceros.

Por lo tanto, debes rastrear también las respuestas de las API de terceros. En nuestra experiencia, las dependencias defectuosas han creado muchas conmociones cuando no las hemos analizado de manera independiente.

3. Implementa Pruebas Automatizadas en la Monitorización de la API

Si tienes una canalización CI/CD bien definida, probablemente ya conoces la importancia de la automatización. Por lo tanto, lo mejor es que puedas configurar pruebas automatizadas para tus puntos finales de la API junto con la monitorización. Deberías considerar la posibilidad de añadir un paso adicional en tus canalizaciones CI/CD para ejecutar pruebas automatizadas en tus puntos finales antes de un lanzamiento. Aunque esto se ha convertido en una norma en los tiempos actuales, deberías comprobar si lo has implementado o no.

4. Elige una Herramienta con una Fuerte Funcionalidad de Alerta

Con la variedad de herramientas disponibles en el mercado actual, puede resultar complicado encontrar la adecuada para tu caso de uso. Para facilitarte la búsqueda, aquí tienes una regla rápida que debes recordar: Busca siempre una gran capacidad de alerta. Si la herramienta que has elegido no te avisa adecuadamente de los problemas que se producen, tendrás que perder tiempo interviniendo constantemente para verificar si se ha producido algún evento. La automatización en este ámbito contribuye en gran medida a aumentar la productividad de tu equipo.

5. Da Prioridad a las Herramientas que se Pueden Integrar Directamente en tu Cadena de Producción de CI/CD

Deberías considerar la posibilidad de integrar la monitorización en cada etapa de tus pipelines CI/CD para analizar la eficiencia de tus procesos DevOps. Para ello, debes seleccionar cuidadosamente las herramientas que ofrezcan dicha funcionalidad.

Para comprobar si la herramienta que has elegido la tiene, busca la lista de integraciones de terceros que proporciona. Si tu servidor de CI, como Jenkins o GitHub, es compatible con la herramienta, ¡estás listo!

6. Nunca Comprometas la Privacidad de la API

Algunas herramientas de monitorización de la API aprovechan las plataformas SaaS de terceros que requieren que los clientes abran ciertos puertos en sus cortafuegos para monitorizar las API internas, que de otro modo serían inalcanzables. Sin embargo, esto supone un gran riesgo para la seguridad. Cualquiera que conozca estos puertos puede utilizarlos para obtener acceso no autorizado a tus sistemas.

Por eso es imprescindible elegir una buena solución de monitorización de API que tenga en cuenta el diseño de tu API y te permita monitorizar cada punto final, ya sea interno o externo, de forma segura. Las mejores herramientas para este fin son las que pueden acceder a tus API internas de forma privada sin dejar espacio a los intrusos.

7. Supervisa las 24 Horas del Día, los 7 Días de la Semana

No supervisar tus API literalmente todo el tiempo puede costarte una gran fortuna. Cualquier servicio puede caerse en cualquier momento. Y si tu servicio de monitorización está apagado en ese momento, tendrás que esperar a que el servicio vuelva a funcionar para saber que se ha producido la caída. Puedes perder un valioso negocio en esa ventana.

Por tanto, te sugerimos que configures monitores de alta frecuencia que se ejecuten al menos cinco veces por hora para las pruebas funcionales, y una vez por hora para la supervisión de la seguridad y de OAuth.

8. Prefiere la Monitorización Externa a la Interna

Muchas veces, los problemas no se producen de manera uniforme a nivel interno y externo. Tus usuarios pueden enfrentarse a un problema que no puedes reproducir dentro de los cortafuegos de tu sistema. En ese caso, no importa si tus métricas internas funcionan correctamente; el usuario no puede acceder a tu producto, por lo que toda métrica operativa no sirve de nada.

Para evitar este tipo de situaciones, prefiere siempre una configuración de monitorización externa a una interna. Para solucionar los problemas de tus usuarios, tienes que mirar tus API desde la perspectiva del usuario.

9. Supervisa Todos los Recursos

En el proceso de construcción del servicio o aplicación que hay detrás de tu API, puede que diseñes algunos componentes básicos o complejos. Aunque puede ser tentador saltarse la monitorización de los componentes esenciales, no es una buena práctica en todos los casos. Muchas veces, un error aparentemente trivial en un componente simple y sin importancia puede romper una aplicación extensa.

Si no tienes ojos en todas partes, te verás obligado a perder horas tratando de encontrar el componente que causó el problema, solo para descubrir que la pequeña pieza que considerabas demasiado inocente para fallar es en realidad la culpable.

10. Analiza Todos los Parámetros de la Respuesta

Comprobar únicamente que el código de estado devuelve 200 no es suficiente. La mayoría de los desarrolladores utilizan códigos de estado HTTP básicos, como 200 para el éxito y 500 para el error del servidor, para denotar respuestas genéricas. Sin embargo, el éxito o el error pueden ser de varias formas, y el seguimiento de cada instancia es esencial para determinar el rendimiento de tus API.

También debes considerar la posibilidad de buscar cambios en el tamaño del contenido devuelto por las API. Si la respuesta habitual tiene un tamaño de 500 kb, pero solamente has recibido 100 kb o menos, probablemente te has encontrado con algún tipo de fallo.

Herramientas de Supervisión de la API

Para poner en práctica las mejores prácticas mencionadas anteriormente, tienes que empezar con una solución de monitorización de la API. Aunque hay plugins listos para usar en frameworks como WordPress for API monitoring, tienes que buscar una solución más completa en el caso de aplicaciones puramente codificadas.

En la siguiente sección, hablaremos de una breve serie de herramientas de monitorización de API que están de moda y que te ayudarán a empezar con un coste y un esfuerzo mínimos.

Uptrends

El panel de control de la cuenta de Uptrends.
El panel de control de la cuenta de Uptrends.

Uptrends ofrece monitorización para aplicaciones web, API, servidores y mucho más. Cuenta con una amplia base de clientes de más de 25.000 pequeñas y grandes organizaciones, entre las que se encuentran algunos nombres destacados como Microsoft, Vimeo y Volkswagen.

Una característica llamativa que ofrece este proveedor es la prueba basada en el navegador. Utiliza navegadores reales y únicos para ejecutar tus aplicaciones y sitios web y capturar métricas detalladas sobre su rendimiento.

Sin embargo, los tiempos de respuesta y las métricas no son las únicas características del servicio. Con Uptrends, también obtienes un informe detallado sobre el rendimiento de cada uno de tus recursos, para que entiendas todos los posibles tipos de cuellos de botella de tu sistema. Para cada error, Uptrends hace una captura de pantalla y te la envía para que puedas experimentar el error tal y como se ha producido.

Dotcom-Monitor

El panel del informe de rendimiento de Dotcom-Monitor.
El panel del informe de rendimiento de Dotcom-Monitor.

Dotcom-Monitor se enorgullece de permitir a los usuarios configurar un dispositivo de supervisión multitarea mediante un trabajo HTTP o HTTPS. Esto te permite monitorizar las API web para comprobar su disponibilidad, sus respuestas adecuadas y su rendimiento.

Los agentes de Dotcom-Monitor replican una o varias peticiones de clientes para verificar si los datos pueden intercambiarse adecuadamente entre la API y los clientes. Cuando uno de los agentes detecta un error, lo comprueba con una lista de filtros preestablecidos. Si el error no está configurado para ser filtrado, el agente lanza una alerta.

La herramienta te permite configurar horarios de alerta personalizados y alternativas de escalado. Puedes exportar los informes de errores en varios formatos, como CSV, PDF, TXT, etc. Los informes de errores de Dotcom-Monitor muestran diferentes métricas valiosas, como los tiempos de inactividad, los tiempos de respuesta y el rendimiento medio por ubicación.

Dotcom-Monitor se encuentra entre las soluciones de monitorización de API más asequibles, y sus planes empiezan desde 1,99 $ al mes. Si eres una organización en crecimiento con un presupuesto limitado, Dotcom-Monitor podría ser la solución de monitorización de API adecuada para ti.

Graphite

El panel de control de la API de Graphite.
El panel de control de la API de Graphite.

Graphite es un sistema de monitorización de API de código abierto que te permite capturar métricas de las API haciendo que el servicio envíe los datos al componente Graphites Carbon. A continuación, Graphite almacena estos datos en una base de datos para obtener información sobre ellos.

Graphite es popular entre sus usuarios por la sencillez que ofrece en el proceso de instalación, que incluye un script de instalación y configuración automatizada de su pila, conocido como Synthesize.

Otra característica llamativa que ofrece Graphite es la capacidad de almacenar eventos arbitrarios. Estos eventos suelen estar relacionados con métricas de series temporales. También puedes añadir y hacer un seguimiento de los despliegues de la aplicación o la infraestructura dentro de Graphite, lo que permite a tu equipo de desarrollo encontrar el origen de los problemas y los cuellos de botella más rápidamente y obtener más contexto sobre los eventos y las anomalías que conducen a un comportamiento inesperado.

Sematext

El panel de control de Sematext Synthetics.
El panel de control de Sematext Synthetics.

Sematext es una solución popular entre los equipos de DevOps, debido al conjunto de herramientas de monitorización que ofrece. La monitorización de la API es una parte de su servicio de monitorización sintética, que se conoce como Sematext Synthetics.

Sematext proporciona un complejo sistema de supervisión y alerta de la API que puedes personalizar para que funcione en función de varios errores y métricas. Puedes configurar esta herramienta para que realice una doble o triple comprobación antes de enviar una alerta. Puede ayudarte a eliminar los falsos positivos de tus alertas y proporcionar información más precisa y relevante.

Junto con el potente monitor HTTP que ofrece Sematext, también obtienes una completa función de monitorización del navegador. Te permite recopilar métricas de rendimiento de la web basadas en las interacciones preestablecidas de los usuarios con tus aplicaciones web. Esto significa que puedes ir más allá de los estándares de prueba habituales de seguimiento de los tiempos de carga de la página, los tiempos de pintura del contenido, etc., y echar un vistazo más profundo a las interacciones detalladas emuladas del usuario, como el flujo de autenticación dentro de la aplicación, la ejecución de consultas de búsqueda o la adición o eliminación de artículos de un carrito. Sematext proporciona varias de estas interacciones de usuario de forma inmediata.

BlazeMeter

El panel de control de la API de BlazeMeter.
El panel de control de la API de BlazeMeter.

Blazemeter es una solución de pruebas y monitorización de extremo a extremo para aplicaciones modernas. La herramienta te da total libertad para elegir marcos de pruebas de código abierto y analizarlos mediante sencillos cuadros de mando. También ofrece una perfecta integración con Apache JMeter, que se encuentra entre las mejores herramientas de medición del rendimiento para aplicaciones web complejas.

Como la mayoría de las soluciones de monitorización de API, BlazeMeter también ofrece características fundamentales como las pruebas funcionales (denominadas «escenarios»), que puedes configurar mediante una interfaz gráfica de usuario interactiva. BlazeMeter expuso un DSL (Lenguaje Específico de Dominio) a través de su herramienta de pruebas dedicada Taurus que permite a los desarrolladores escribir pruebas genéricas. Luego pueden ejecutar estas pruebas con JMeter y otras herramientas populares de código abierto.

Dado su pesado diseño, BlazeMeter tiene un precio más elevado. Si tu aplicación tiene más de 5.000 usuarios simultáneos, debes estar preparado para desembolsar más de 600 dólares al mes. Sin embargo, puedes optar por planes de coste fijo basados en tu uso.

Si tu producto se encuentra en la línea de Pfizer, Adobe, NFL, Atlassian, etc., BlazeMeter es la solución de monitorización de API perfecta para ti.

Aunque esta es una colección bastante concisa de herramientas de supervisión de API, hay muchas más opciones estupendas por ahí. ¡Asegúrate de consultar la colección detallada de herramientas de monitorización de API de Geekflare y la completa guía de compra de herramientas de monitorización de API de Sematext antes de hacer una elección!

Resumen

Las API son la columna vertebral de la maquinaria informática moderna. La mayoría de los productos del mercado de software vienen con una API para ofrecer una integración perfecta con entidades de terceros. Para ofrecer una experiencia de usuario fluida y retener a tus clientes, debes considerar la posibilidad de crear y ofrecer una API con tu producto de software… lo que significa que debes conocer las API al dedillo.

Esta guía está pensada para ayudarte a introducirte en este campo, presentándote los fundamentos de la tecnología, incluyendo la ilustración de los conceptos básicos, las mejores prácticas y las útiles herramientas de monitorización de API del mercado. Esperamos que ahora entiendas mejor cómo se comunican los recursos web entre sí.

Sin embargo, a pesar de todo lo que hemos hablado, apenas hemos arañado la superficie en lo que respecta a todo lo que pueden lograr las API y los puntos finales de las API. Sigue leyendo, probando y acudiendo a la comunidad de desarrolladores para ampliar tus conocimientos y habilidades con los puntos finales de la API.