API do Serviço Nacional de Parques dos EUA

Artigo original ↗ Discussão no Hacker News ↗

Uma API pública do U.S. National Park Service está a ser elogiada por disponibilizar dados dos parques, ao mesmo tempo que recebe críticas sobre a forma como é implementada e financiada. Os comentadores debatem se uma API REST na AWS com chaves de API é uma forma apropriada de servir conjuntos de dados maioritariamente estáticos, ou se abordagens mais baratas e abertas, como dumps em CSV ou tabelas públicas no BigQuery, estariam mais alinhadas com a missão de fornecer dados financiados pelos contribuintes. O debate também aborda questões mais amplas sobre a capacidade tecnológica do governo, o subfinanciamento dos serviços digitais e os compromissos entre facilidade de acesso, prevenção de abuso e manutenção a longo prazo.

Receção Geral e Usos Existentes

  • Muitos comentadores estão entusiasmados com o facto de o National Park Service (NPS) expor uma API pública e ter presença no GitHub, apesar de alguns repositórios estarem desatualizados.
  • Uma pessoa espelhou partes da API num conjunto de dados público do BigQuery para facilitar a análise em SQL/Jupyter e publicou documentação/código.
  • As pessoas mencionam fontes de dados secundárias interessantes (por exemplo, estatísticas do IRMA) e visualizações personalizadas criadas com base nos dados de afluência do NPS.

Debate sobre Alojamento, Custo e Arquitetura

  • Um grande subthread argumenta que REST em AWS/EC2 é uma forma cara e excessivamente complexa de servir principalmente CSV/JSON estáticos.
  • Alternativas propostas:
    • Conjuntos de dados públicos do BigQuery com modelo de “quem consulta paga”.
    • Dumps estáticos de CSV ou SQLite em armazenamento barato (por exemplo, S3) mais espelhos.
  • Contra-argumentos:
    • As APIs REST são mainstream, testadas no terreno e fáceis de integrar.
    • O tráfego real pode ser suficientemente baixo para que os custos sejam insignificantes face ao orçamento global do NPS.
    • Alguns dados (alertas, eventos) são dinâmicos; o sistema subjacente usa, segundo consta, Apache Solr.
  • Há desacordo sobre se as poupanças são substanciais; os críticos são pressionados a fornecer estimativas concretas de custos.

Acesso Público, Chaves de API e Limitação de Taxa

  • Debate sobre chaves de API para dados públicos:
    • Os críticos veem-nas como fricção desnecessária e um mecanismo de rastreio pouco adequado a dados governamentais abertos.
    • Os apoiantes dizem que as chaves são a ferramenta mais simples para limitação de taxa, controlo de abuso e contabilização de uso quando a agência paga por pedido.
  • Alternativas sugeridas: limites baseados em IP com registo opcional para quotas mais altas; outros argumentam que controlos apenas por IP são fracos, especialmente em IPv6 ou através de aplicações populares.
  • Alguns receiam empurrar os utilizadores para plataformas ligadas a fornecedores (por exemplo, BigQuery) em vez de acesso HTTP neutro em relação a fornecedores, financiado por impostos.

Financiamento, Manutenção e Contexto do Governo Digital

  • A equipa da API é descrita como subdimensionada e efetivamente em modo de manutenção; o roadmap não é atualizado desde 2017.
  • A discussão desvia-se para iniciativas federais mais amplas de digitalização (USDS, 18F), a sua dependência de vontade política e a compensação em comparação com os salários do setor privado.

Cobertura de Dados, Lacunas e APIs Relacionadas

  • Funcionalidades em falta ou desejadas: API de reservas (gerida via recreation.gov), disponibilidade em tempo real de campismo, telemetria em direto (por exemplo, seguimento de vida selvagem) e estatísticas de visitantes via a API.
  • Inexatidões notadas: discrepâncias no número de parques e listagens combinadas (por exemplo, Sequoia/Kings Canyon).
  • Pequenas perguntas laterais sobre APIs de terrenos do BLM e endpoints não documentados do NPS descobertos via inspeção do site.