23 ¿Es necesario el desarrollo de una API?

Una cuestión importante y que debe ser tomada en cuenta en la apertura de bases de datos es el desarrollo de una API (Application Programming Interface), para poner a disposición la información en la Web. Una API, en el marco de interés de esta guía es, en palabras simples, un elemento de interacción entre una base de datos y una aplicación que se alimenta con dichos datos. La API le ofrece al desarrollador/emprendedor interesado una serie de llamadas estándar para que extraiga datos de de terminada base mediante requisiciones en la Web. El desarrollo de una API requiere de un refinado conocimiento técnico y, en caso de que ella sea pública, de la definición de estándares arbitrarios que apuntan a prever los casos en que el desarrollador/emprendedor necesitará de los datos. Una API ofrece una serie de ventajas, como el acceso facilitado y rápido a las bases de datos. En vez de descargar la base entera, alcanza con que el programador realice una requisición simple en la Web para que sea extraída la porción que le interesa en ese momento. La API también permite acceso en tiempo real a partes específicas de la base, haciendo posible la creación de aplicaciones que dependen de datos de rápida actualización.

Las APIs pueden ser privadas, cuando un desarrollador tiene control sobre el banco de datos y crea la API para facilitar el acceso a los mismos; o públicas, cuando el encargado de una base de datos desarrolla una API de utilidad para la comunidad de desarrolladores/emprendedores, buscando prever qué tipo de requisiciones al banco de datos habrán de ser lo suficientemente útiles y genéricas como para atender el mayor número de aplicaciones posible. Servicios como Facebook and Twitter poseen APIs públicas que hacen posible que programadores de todo el mundo interactúen, de manera limitada, con la inmensa cantidad de datos que dichas empresas albergan.

En el ámbito gubernamental, a pesar de las ventajas, el desarrollo de una API puede derivar en situaciones incómodas, dependiendo del caso. Es necesario reflexionar con cuidado acerca de si el desarrollo de una API es el mejor camino a seguirse, pues existen alternativas que pueden funcionar mejor para ambas partes: tanto para el desarrollador interesado en los datos gubernamentales como para los equipos de servidores públicos o tercerizados contratados que tendrían la misión de mantener las APIs funcionando de manera estable y confiable.

Un escenario ficticio

Imagine, por ejemplo, que la Secretaría de Logística y Transporte del Estado de San Pablo haya desarrollado una API pública para que cualquier desarrollador pueda acceder a información sobre las condiciones de mantenimiento de las autovías paulistas. En determinado momento, el servidor de API resulta sobrecargado y el servidor del banco de datos se detiene. Los servicios estatales que dependen de ese banco de datos dejaron de funcionar. Los registros mostraron que hubo un enorme aumento de tránsito entre las ocho y las nueve la mañana, con numerosas llamadas de API provenientes de variados y diferentes lugares. Luego de las nueve horas, el nivel de acceso a los servidores disminuye y todo vuelve a la normalidad.

¿Qué sucedió?

Continuando con el escenario ficticio, un año antes, la Secretaría de Logística y Transporte comenzó con su apertura de datos como parte de la política de transparencia estatal. Había prisa, y con un equipo reducido, ellos decidieron crear una API para los datos de las autovías, configurando un servidor de API al cual pudiese accederse a través de Internet. La API fue desarrollada tomando en cuenta potenciales situaciones en las que los desarrolladores de aplicaciones podrían utilizarlas, pero era difícil saber exactamente lo que las personas habrían de querer. En total, el equipo de la Secretaría estableció tres llamadas genéricas de API.

Sucedido lo narrado con los servidores, un año más tarde, los desarrolladores descubrieron que un emprendedor había programado una aplicación para celulares que tuvo gran éxito, pasando a ser utilizado por cientos de miles de personas. Todos los días, por la mañana, la aplicación anunciaba, antes de que las personas salieran hacia su trabajo, cuál era la situación de mantenimiento de las autovías paulistas. Para bajar tales datos, cada aplicación instalada en cada celular necesitaba realizar dos llamadas API. Fue eso lo que hizo caer los servidores de la Secretaría, ya que la infraestructura no estaba preparada para enfrentarse a semejante cantidad de accesos.

Alternativa

Una alternativa al modelo presentado anteriormente es la de publicar "dumps" de datos en forma de archivos. De acuerdo a ese modelo, los datos de la base son exportados y transformados en un archivo de formato abierto, tal como el CSV. Luego del proceso, reciben un nombre estandarizado y se los almacena en un servidor de páginas Web. Eso implica que cualquier desarrollador puede bajar todos sus datos, cargarlos en la infraestructura propia y desarrollar las propias APIs (en este caso, privadas), de acuerdo a sus necesidades. Además de eso, una gran cantidad de accesos habrá de concentrarse en sus servidores, sin afectar el funcionamiento de otros servicios del gobierno. Otra ventaja es que la publicación de archivos "dumps" en un servidor de páginas Web es sumamente simple. Si los archivos y las URLs reciben nombres consistentes, será fácil para los desarrolladores bajar los datos todo el tiempo (por ejemplo, http://ejemplo.com/autovias/2015-01-30.csv).

Consideraciones

● ¿Necesita usted realmente una API? Desarrollar una API puede convertirse en un proyecto caro, que competirá con otros proyectos de TI con mayor prioridad. Además, este tipo de proyectos involucra tomar decisiones sobre qué llamadas serán realizadas. ¿Sabe usted de qué manera sus usuarios habrán de utilizar sus datos? ¿Su API contribuirá a que los usuarios utilicen los datos de la mejor manera posible? ¿Cómo planea enfrentarse a una inmensa cantidad de accesos?

● Cree condiciones para que los desarrolladores mantengan una copia local y actualizada de sus datos. La oferta de "dumps" de datos denominados de manera consistente simplifica el proceso de mantener una base de datos actualizada.

● Aísle los sistemas internos de los efectos de la publicación externa de datos. Tome los debidos cuidados para que los accesos provenientes de la Web no interfieran con las bases de datos internas, afectando así a otros servicios del Gobierno.

● Certifíquese de que usted puede cambiar sus sistemas sin modificar las URLs. Los desarrolladores van a programar aplicaciones que dependen de sus URLs. No los fuerce a reescribir sus programas sólo porque usted va a cambiar de plataforma. Signos de que las cosas pueden ser mejor planificadas incluyen fragmentos pertenecientes a plataformas específicas, como "aspx" o "jsp" en sus URLs. Líbrese de ellos.