API del Servicio de Parques Nacionales de EE. UU.

Artículo original ↗ Discusión en Hacker News ↗

Se está elogiando una API pública del National Park Service de EE. UU. por abrir los datos de los parques, aunque también recibe escrutinio por cómo está implementada y financiada. Los comentaristas debaten si una API REST en AWS con claves de API es una forma apropiada de servir conjuntos de datos en gran medida estáticos, o si enfoques más baratos y abiertos como volcados CSV o tablas públicas de BigQuery encajarían mejor con la misión de proporcionar datos financiados por los contribuyentes. El hilo también aborda cuestiones más amplias de capacidad tecnológica gubernamental, falta de financiación de los servicios digitales y las compensaciones entre facilidad de acceso, prevención del abuso y mantenimiento a largo plazo.

Recepción general y usos existentes

  • Muchos comentaristas están entusiasmados de que el National Park Service (NPS) exponga una API pública y tenga presencia en GitHub, a pesar de que algunos repos están desactualizados.
  • Una persona replicó partes de la API en un conjunto de datos público de BigQuery para facilitar el análisis con SQL/Jupyter y publicó documentación/código.
  • La gente menciona fuentes de datos secundarias interesantes (por ejemplo, estadísticas de IRMA) y visualizaciones personalizadas construidas sobre los datos de visitas del NPS.

Debate sobre alojamiento, costo y arquitectura

  • Un subhilo grande argumenta que REST sobre AWS/EC2 es una forma costosa y sobredimensionada de servir principalmente CSV/JSON estáticos.
  • Alternativas propuestas:
    • Conjuntos de datos públicos de BigQuery con el modelo de “quien consulta paga”.
    • Volcados estáticos de CSV o SQLite en almacenamiento barato (por ejemplo, S3) más espejos.
  • Contraargumentos:
    • Las APIs REST son convencionales, probadas en batalla y fáciles de integrar.
    • El tráfico real puede ser lo bastante bajo como para que los costos sean insignificantes en relación con el presupuesto total del NPS.
    • Algunos datos (alertas, eventos) son dinámicos; según se informa, el sistema subyacente usa Apache Solr.
  • Hay desacuerdo sobre si el ahorro sería sustancial; a los críticos se les pide que aporten estimaciones de costo concretas.

Acceso público, claves de API y limitación de tasa

  • Debate sobre las claves de API para datos públicos:
    • Los críticos las ven como fricción innecesaria y un mecanismo de seguimiento inadecuado para datos gubernamentales abiertos.
    • Los defensores dicen que las claves son la herramienta más simple para limitar la tasa, controlar abusos y contabilizar el uso cuando la agencia paga por solicitud.
  • Se sugieren alternativas: límites basados en IP con registro opcional para cuotas más altas; otros argumentan que los controles basados en IP por sí solos son débiles, especialmente con IPv6 o mediante aplicaciones populares.
  • Algunos temen que se empuje a los usuarios hacia plataformas atadas a un proveedor (por ejemplo, BigQuery) en lugar de acceso HTTP neutrales respecto al proveedor y financiados con impuestos.

Financiación, mantenimiento y contexto de gobierno digital

  • El equipo de la API se describe como con personal insuficiente y, en la práctica, en modo de mantenimiento; la hoja de ruta no se ha actualizado desde 2017.
  • La discusión se amplía a iniciativas federales más amplias de tecnología digital (USDS, 18F), su dependencia de la voluntad política y la compensación frente a los salarios del sector privado.

Cobertura de datos, lagunas y APIs relacionadas

  • Funciones faltantes o deseadas: API de reservas (gestionada vía recreation.gov), disponibilidad en tiempo real de campamentos, telemetría en vivo (por ejemplo, seguimiento de vida silvestre) y estadísticas de visitantes a través de la API.
  • Se señalan inexactitudes: discrepancias en el conteo de parques y listados combinados (por ejemplo, Sequoia/Kings Canyon).
  • Breves preguntas secundarias sobre APIs de tierras de BLM y endpoints de NPS no documentados descubiertos mediante inspección del sitio.