Una API a prueba de bombas: cómo impedir que tu plataforma muera de éxito

3 min lectura
Desarrollo , Negocio API / 15 septiembre 2016
Una API a prueba de bombas: cómo impedir que tu plataforma muera de éxito
Una API a prueba de bombas: cómo impedir que tu plataforma muera de éxito

BBVA API Market

El sueño de todo desarrollador es que su última creación alcance la fama mundial. En el caso de una API, tanto su padre como la compañía que lance esta herramienta que permita utilizar y conectar sus servicios con plataformas de terceros, estarán más que orgullosos al ver su éxito. Pero no es oro todo lo que reluce y este triunfo puede convertirse en todo un problema.

De hecho, de no estar creada de forma correcta, una API puede verse avasallada al llegar a ser popular y caer ante una avalancha de peticiones. Así, el uptime, el tiempo de actividad, se convierte en el indicador clave que demuestra lo útil y fiable que es en realidad la herramienta en cuestión. La aspiración de todo desarrollador debe ser que su API llegue a un uptime que roce el 100% y es que, cuanto mayor sea este marcador, mayor fortaleza demostrará la API.

En primer lugar, es necesario ser consciente de las limitaciones de las infraestructuras que sostienen el servicio: saber cuánto da de sí el ancho de banda para conocer el número de conexiones simultáneas que se pueden aceptar o la cantidad de datos que pueden llegar a ser transferidos entre el sistema y los usuarios es clave. Así, se evita desafiar tanto la capacidad de la red como la arquitectura de la propia API y arriesgarse a que una avalancha de solicitudes la lleve de la popularidad a la catástrofe.

No obstante, el proveedor de la API tiene un as bajo la manga ante un caso de éxito: la limitación de la velocidad. Se trata del proceso por el cual la propia API va rechazando solicitudes en función de varios factores, que van desde la avalancha de solicitudes simultáneas hasta el exceso de datos demandados por un mismo usuario. De esta forma, se asegura la fiabilidad de la API, ya que el sistema logra seguir estando a disposición de los usuarios (aunque con las limitaciones impuestas).

Además, esta limitación abre la puerta a un posible negocio alternativo. No en vano, limitar la velocidad permitiría ofrecer planes de suscripción a los usuarios que deseen un volumen alto de peticiones. Este modelo freemium (una API gratuita para accesos básicos y de pago para aumentar la cantidad de peticiones) hace que lo que en principio es un problema y un sobrecoste que permita mejorar las infraestructuras se convierta en una oportunidad de negocio.

Una API indestructible

A la hora de desarrollar una API capaz de soportar ataques y avalanchas, el abanico de posibilidades para lograr crearla es amplio. Para empezar, más allá de conocer las limitaciones de capacidad, los desarrolladores también deben tener en cuenta factores físicos como el estado de los servidores en los que se almacenan los datos para que ninguna rotura provoque una sorpresa desagradable, la ubicación exacta de la nube que utiliza para guardarlos o su distancia respecto a los usuarios del servicio (al fin y al cabo, los datos tardan en transmitirse y una distancia excesiva puede ser un problema).

Además, establecer unos límites de capacidad de los servidores demasiado bajos o excesivamente ajustados a la actividad habitual puede ser la muerte de la API: cualquier repunte puede desbordar el servicio y colapsarlo hasta tal punto que sea imposible conectarse a él. Es lo que en la internet anglosajona se conoce como efecto Reddit o en la de habla hispana como efecto Meneame: si una web, aplicación o servicio logra llamar la atención en el agregador, más vale que el servidor esté preparado para una multitud de peticiones que amenazan con arrasar con su estabilidad.

Por otra parte, y para asegurar que la transferencia de información entre el usuario y la API se produce sean cuales sean las condiciones, también es necesario abrazar la conmutación por error: establecer rutas alternativas para que, en caso de fallo, el intercambio no se bloquee, sino que simplemente cambie de camino.

Para que todo ello funcione a la perfección, el equipo de desarrollo también debe limar el código lo necesario para que en él se contemplen todas las posibles situaciones e incluya excepciones de cualquier tipo, desde los fallos posibles de memoria hasta los propios desbordamientos del sistema. Así, la API podrá reaccionar de forma eficiente ante cualquier contratiempo. De esta forma, construir una herramienta con lo básico para poder lanzarla es, a medio plazo, un grave y costoso error que hará que el uptime se desplome pronto.

Por último, y para evitar cualquier tipo de ataque, nada mejor que ser crítico y utilizar la API como saco de boxeo: el desarrollador debe ser, a la vez, todo un sombrero blanco que explore las posibles debilidades y vulnerabilidades de la API que puedan ser aprovechadas por un atacante para bloquear el acceso al servicio, por ejemplo, mediante un ataque DDoS.

Todo ello, sin olvidar que la solución a todos los problemas que puedan surgir en la vida de una API debe ser compatible con su evolución y desarrollo constante, para hacer de ella una herramienta en constante estado de mejora. Así, el camino hacia su éxito será mucho más llano.

¿Te interesan las APIs financieras? Consulta el catálogo de BBVA en esta web

También podría interesarte