Página Notícia
Ordenação é "escondida" na API 0.2.6
Parâmetros não- ou parcialmente implementados, que geraram reclamações dos usuários, não serão divulgados até a correção dos problemas
Na atualização de 04/10/2017, a API do Dados Abertos traz mais alguns pequenos passos adiante – mas também um importante passo para trás.
Mudanças e correções
- Por e-mail e pela nossa página no GitHub, usuários vinham reclamando que, em alguns endpoints, os parâmetros de ordenação ordem e ordenarPor não estavam funcionando – ou, pior ainda, causavam erro no servidor, com retorno de status 500.
A verdade é que, em vários dos endpoints, os parâmetros foram apenas parcialmente implementados, ou nem mesmo foram implementados, e ainda assim já estavam na lista de parâmetros de cada endpoint na página de descrição da API.
Foi um erro de comunicação nosso e pedimos desculpas aos nossos usuários por isso. A ordenação foi revisada em todos os endpoints já publicados em que a funcionalidade é prevista, e a página de descrição da API foi atualizada para não mais se referir a parâmetros que não estão funcionando como deveriam. Em alguns casos, o parâmetro ordenarPor já está implementado, e pode receber como valor um nome de campo dos itens retornados. Em todos os endpoints o parâmetro ordem ainda não foi implementado corretamente e por isso, em algumas ocasiões, causa o erro 500. A recomendação, por enquanto, é não tentar utilizar os parâmetros sem consultar a descrição dos respectivos endpoints a cada nova versão da API que for publicada.
- /orgaos - Um novo campo foi inserido nos itens retornados: o apelido de comissões e conselhos, que muitas vezes é bem mais conciso e esclarecedor do que os nomes oficiais que são criados. Esta mudança atende a uma demanda interna e imaginamos que também poderá ser útil para desenvolvedores externos.
- /legislaturas/{id} - Corrigido um problema de malformação da seção "links", que estava com nome errado e sem conteúdo.
- /orgaos - Descobrimos que a consulta à base de dados não estava sendo feita corretamente. A especificação diz que, se estiverem presentes os parâmetros dataInicio e/ou dataFim, devem ser retornados os órgãos em funcionamento nesse período. Mas, até esta atualização, estavam sendo retornados somente os órgãos temporários criados no intervalo de tempo. Além disso, corrigimos uma diferença de comportamento quando estava presente na requisição o parâmetro dataFim, que, quando ausente, deve ser entendido como o dia da requisição.
- /proposicoes/{id}/votacoes - Por e-mail, o usuário Washington Araújo nos informou que estava recebendo um erro 404 ao requisitar a lista de votações do PL 139/2017 (id 2122124). Ele descobriu que o endpoint foi implementado sem considerar um importante conceito da nova API: se {id} é válido, ele obrigatoriamente terá todos os recursos subordinados que a API define para ele – mesmo que sejam apenas listas vazias. Como o PL 139/2017 ainda não havia passado por votação alguma, a chamada a /proposicoes/2122124/votacoes deveria retornar status 200 e trazer a seção "dados" vazia – e é isso que está acontecendo agora.
- /proposicoes/{id}/tramitacoes - Dois problemas foram detectados e corrigidos. Agora, o campo "uriOrgao" de cada item traz a URL correta que identifica e permite obter dados sobre o órgão onde cada evento de tramitação ocorreu. Além disso, no retorno em formato XML, cada registro de uma tramitação está agora corretamente identificado como um nó <statusProposicao>.