25 O desenvolvimento de uma API é necessário?

Uma questão importante a ser levada em consideração na abertura de bases de dados é o desenvolvimento de uma API (Application Programming Interface) para servir informações na Web. Uma API, no escopo deste guia e de forma resumida, é uma camada de interação entre uma base de dados e um aplicativo que se alimenta desses dados. A API oferece ao desenvolvedor/empreendedor interessado uma série de chamadas padrões para se extrair dados de determinada base por meio de requisições na Web. O desenvolvimento de uma API requer conhecimento técnico refinado e, caso ela seja pública, a definição de padrões arbitrários, que tentam antever os casos em que o desenvolvedor/empreendedor precisará dos dados. Uma API apresenta uma série de vantagens, como o acesso facilitado e rápido às bases de dados. Em vez de baixar a base de dados inteira, basta que o programador faça uma chamada simples na Web para extrair a porção que interessa a ele naquele momento. Ela também facilita o acesso em tempo real a partes específicas da base, permitindo a criação de aplicações que dependem de dados atualizados rapidamente.

As APIs podem ser privadas, quando um desenvolvedor tem controle sobre o banco de dados e cria a API para facilitar o acesso aos dados; ou públicas, quando o guardião de uma base de dados desenvolve uma API para servir a comunidade de desenvolvedores/empreendedores, procurando antever quais tipos de requisições ao banco de dados serão úteis e genéricas o suficiente para atender o maior número de aplicações possíveis. Serviços como o Facebook e o Twitterpossuem APIs públicas que permitem programadores de todo mundo interagirem, de forma limitada, com a imensidão de dados que essas empresas abrigam.

No âmbito do governo, apesar das vantagens, o desenvolvimento de uma API pode trazer situações desconfortáveis, dependendo do caso. É preciso refletir com cuidado se o desenvolvimento de uma API é o melhor caminho a ser seguido, pois há alternativas que podem funcionar melhor para ambos os lados: tanto para o desenvolvedor interessado nos dados governamentais, quanto para as equipes de servidores públicos ou terceirizados pelo estado que teriam a missão de manter as APIs funcionando de maneira estável e confiável.

Um cenário fictício

Imagine que a Secretaria de Logística e Transportes do Estado de São Paulo tenha desenvolvido uma API pública para que qualquer desenvolvedor pudesse acessar informações sobre as condições de manutenção das estradas paulistas. Em determinado momento o servidor de API foi inundado e o servidor do banco de dados travou. Os serviços estaduais que dependem desse banco de dados pararam de funcionar. Os registros mostravam que houve um aumento grande no tráfego entre oito e nove horas da manhã com muitas requisições de API vindas de muitos lugares diferentes. Depois das nove horas o nível de acessos nos servidores diminuiu e tudo voltou ao normal.

O que aconteceu?

Seguindo com o cenário fictício, um ano antes, a Secretaria de Logística e Transportes começou a abrir seus dados como parte da política de transparência do estado. Havia pressa e, com a equipe reduzida, eles decidiram criar uma API para os dados das estradas configurando um servidor de API acessível pela Internet. A API foi desenvolvida levando em consideração potenciais situações em que os desenvolvedores de aplicativos poderiam usá-la, mas era difícil saber exatamente o que as pessoas iriam querer. Ao todo, a equipe da Secretaria estabeleceu três chamadas genéricas de API.

Passado o ocorrido com os servidores, um ano mais tarde, os servidores descobriram que um empreendedor havia desenvolvido um aplicativo de celular que fez muito sucesso, sendo usado por centenas de milhares de pessoas. Todos os dias de manhã o aplicativo anunciava, antes da pessoa ir trabalhar, qual era a situação de manutenção nas estradas paulistas. Para baixar esses dados cada aplicativo instalado em cada celular precisava realizar duas chamadas de API. Foi isso que derrubou os servidores da Secretaria, pois a infraestrutura não estava preparada para lidar com o número de acessos.

Alternativa

Uma alternativa ao modelo apresentado anteriormente é publicar "dumps" de dados na forma de arquivos. Nesse modelo, os dados da base são exportados e transformados num arquivo de formato aberto, tal como o CSV. Depois disso, recebem um nome padronizado e são armazenados num servidor de páginas da Web. Isso significa que qualquer desenvolvedor pode baixar todos os seus dados, carregá-los na infraestrutura deles e desenvolver suas próprias APIs (nesse caso, privadas) de acordo com a necessidade deles. Além disso, grandes quantidades de acesso estarão concentradas nos servidores deles, sem afetar o funcionamento de outros serviços do governo. Outra vantagem é que a publicação de arquivos "dumps" num servidor de páginas da Web é muito simples. Se os arquivos e URLs receberem nomes consistentes, será fácil para os desenvolvedores baixarem os dados ao longo do tempo (por exemplo, http://exemplo.com/estradas/2015-01-30.csv).

Considerações

● Você realmente precisa de uma API? Desenvolver uma API pode se tornar um projeto caro que vai competir com outros projetos de TI com prioridade maior. Além disso, esse tipo de projeto envolve tomar decisões sobre quais chamadas serão realizadas. Você sabe como seus usuários vão usar seus dados? Sua API vai contribuir para que os usuários utilizem os dados da melhor forma possível? Qual é seu plano para lidar com grandes quantidades de acesso?

● Crie condições para que os desenvolvedores mantenham uma cópia local e atualizada dos seus dados. A oferta de "dumps" de dados nomeados de forma consistente simplifica o processo de manter uma base de dados atualizada.

● Isole sistemas internos dos efeitos da publicação externa de dados. Tome os devidos cuidados para que os acessos vindos da Web não interfiram com bases de dados internas, afetando outros serviços do Governo.

● Certifique-se de que você pode mudar seus sistemas sem quebrar os URLs. Desenvolvedores vão construir aplicativos que dependem dos seus URLs. Não os force a reescrever seus programas apenas porque você vai mudar de plataforma. Sinais de que as coisas podem ser melhores planejadas incluem fragmentos que pertencem a plataformas específicas, como "apsx" ou "jsp", nos seus URLs. Livre-se deles.