A nova API do Dados Abertos entrega dados em XML e JSON de forma paginada. Neste tutorial, você pode saber mais sobre como funciona o mecanismo de paginação, e ver um exemplo em HTML e JavaScript com uma forma de juntar os resultados de diferentes requisições em um só conjunto de dados.
A nova interface de programação de aplicações (API) do serviço Dados Abertos da Câmara foi projetada para fazer jus ao nome: sua finalidade principal é fornecer conjuntos reduzidos de dados, selecionados por meio de diversos parâmetros de busca, para aplicações leves que exibam ou processem esses dados de maneiras particulares. É um tipo de trabalho diferente do que é feito com os arquivos de dados para download, que contêm todas as informações sobre todos os itens de suas respectivas entidades — e por isso exigem disponibilidade de comunicação ("largura de banda") para o download de vários megabytes de uma vez, grandes espaços de memória RAM e processamento intenso na seleção e cruzamento dos dados.
Para manter os conjuntos de dados selecionados relativamente pequenos e a transferência deles mais veloz, a nova API segue um padrão muito comum em outras interfaces que seguem a arquitetura REST: as URLs (ou, mais corretamente, os recursos) que fornecem resultados em listas dividem o resultado em páginas.
Todas as respostas válidas do novo Dados Abertos, tanto em JSON quanto em XML, são entregues em uma estrutura padronizada de organização. Há uma seção com o nome dados
, contendo os resultados
da requisição, e uma seção com o nome links
. O conteúdo de dados
, nos recursos coletivos, é uma lista ordenada de itens que correspondam aos parâmetros de busca utilizados.
<xml> <dados> <partido_> ... </partido_> <partido_> ... </partido_> ... </dados> <links> <link> <rel>self</rel> <href>"..."</href> </link> <link> <rel>next</rel> <href>"..."</href> </link> <link> <rel>previous</rel> <href>"..."</href> </link> <link> <rel>first</rel> <href>"..."</href> </link> <link> <rel>last</rel> <href>"..."</href> </link> </links> </xml>
{ "dados": [ { ... }, { ... }, ... ], "links": [ { "rel": "self", "href": "http://...", }, { "rel": "previous", "href": "http://...", }, { "rel": "next", "href": "http://...", }, { "rel": "first", "href": "http://...", }, { "rel": "last", "href": "http://...", } ] }
Cada elemento link
tem dois campos: href
traz uma URL e rel
é um termo que descreve a relação que a URL tem com o documento ou recurso retornado. Esses termos usados com rel
são de certa forma padronizados, e por serem divulgados no site da Internet Assigned Numbers Authority (IANA) são conhecidos popularmente
como "relações IANA".
Nem sempre todos os links mostrados nos exemplos estão presentes, e não precisam aparecer no resultado nesta mesma ordem. O valor do campo rel
indica os seguintes significados para as URLs:
O uso dos links, e principalmente de suas descrições semânticas dos campos rel
, são recomendações fundamentais da arquitetura REST e da chamada "Web 3.0". É que está na essência de conceitos como linked data e HATEOAS (Hypermedia As The Engine Of Application State, ou "hipermídia como o motor de estado da aplicação").
Na API do Dados Abertos, todos os recursos coletivos (isto é, que fornecem listagens) que têm suporte a paginação usam os mesmos parâmetros de query string para configurá-la:
Para se obter, por exemplo, uma lista de dados de 50 deputados de cada vez, a URL inicial seria .../deputados?itens=50
. Na resposta dessa primeira requisição, haveria um link, identificado com o parâmetro rel
com o valor next
, com a URL já configurada como .../deputados?itens=50&pagina=2
, para a obtenção dos dados dos 50 deputados seguintes.
O correto uso dos elementos link
permite que você obtenha todos os itens de um recurso paginado, de qualquer tamanho total, usando um conceito simples: enquanto cada resposta tiver um link cujo campo rel
tenha o valor next
, é só fazer uma nova requisição usando a URL que esse link traz como valor do campo href
.
É fácil imaginar isso como um loop, mas em linguagens como JavaScript as requisições para obter dados via rede são feitas de maneira assíncrona: logo que a requisição é feita, o fluxo do programa continua
sem esperar a resposta, e é preciso definir o que vai acontecer quando enfim essa resposta chegar. Essa característica exige uma abordagem um pouco diferente daquela de loop WHILE
que se poderia imaginar
para o problema.
Neste tutorial, é criada uma simples página HTML, sem qualquer formatação visual, que monta uma lista com todos os deputados em exercício, usando a API do Dados Abertos, e exibe os nomes desses deputados em um menu tipo combobox. Ao escolher qualquer dos nomes, é exibida na página a foto do parlamentar.
A abordagem dessa aplicação para montar uma só lista com várias requisições (que não pretende ser apresentada como a melhor, é importante observar) é centrada na variável global listaDeps
. É definida
uma função a ser executada quando chegar a resposta, e a cada vez que é chamada essa função acrescenta os dados retornados à lista. No jargão técnico, esse tipo de função, que é invocada como reação de resposta a um evento,
é chamada de callback.
Além de acrescentar itens a listaDeps
, a função verifica a existência de um link cujo rel
seja next
na resposta à requisição. Isso é feito em um loop FOR
que
verifica o conteúdo do campo rel
em todos os nós ou objetos link
que são retornados como itens da lista links
. Há também, comentada, uma versão que usa o método .forEach()
da variável.
Assim que é encontrado um link de rel
igual a next
, a URL que está nesse link, em seu campo href
, é usada como argumento para chamar a função principal que cria uma nova requisição,
buscarListaDeps
. A cada vez que é invocada, buscarListaDeps
cria uma nova callback para a chegada da resposta — e todo o processo se repete até que não haja mais links next
a obter.