El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
El problema de los datos que solo son precisos el día del lanzamiento
Es más fácil sentirse orgulloso de un conjunto de datos el día en que se lanza. Se ha revisado, depurado y validado con las fuentes disponibles en ese momento, y el anuncio puede afirmar con honestidad una buena cobertura y precisión, porque en ese momento concreto se lo ha ganado. El problema es que casi nada de la geografía permanece fijo mucho tiempo. Los límites administrativos cambian. Las autoridades postales redibujan o vuelven a emitir códigos. Los gobiernos modifican las reglas del horario de verano, a veces con muy poco aviso. Un conjunto de datos que era preciso el día del lanzamiento y no se ha mantenido activamente desde entonces ya no es el mismo conjunto de datos, aunque se siga comercializando con la misma seguridad.
La base de datos de zonas horarias de IANA es un ejemplo útil de cómo se gestiona bien esto en la práctica: existe precisamente porque las reglas de zona horaria no dejan de cambiar, y se actualiza a medida que se producen esos cambios, a cargo de personas cuyo trabajo es seguir justo ese tipo de cambios. Una API de geocodificación o de ubicación que se basa en una fuente así y sigue incorporando sus actualizaciones hace algo muy distinto de un proveedor que creó una instantánea única hace años y desde entonces la sirve con pequeños parches.
Creemos que esta distinción, mantenimiento continuo frente a una creación única, merece más atención de la que suele recibir en la forma en que se comercializan los productos de datos de ubicación. Un anuncio de lanzamiento puede afirmar una amplia cobertura de países y será cierto. Lo que no puede prometer por sí solo es que esa cobertura siga siendo cierta dos años después, tras cambios de límites, reorganizaciones postales y modificaciones de reglas de zona horaria que se produjeron discretamente mientras tanto, sin que un cliente tuviera motivo para saber que debía comprobarlo.
Por eso, en parte, tratamos la zona horaria, la elevación y los datos de IP como las partes de nuestro producto que describimos de forma más concreta, ya que son áreas en las que los datos de referencia subyacentes, el tipo de fuente que representa la base de datos de IANA para las zonas horarias, se mantienen de forma continua por diseño y no solo según el calendario interno de actualizaciones de un proveedor. También es la razón por la que tenemos cuidado de no exagerar presentando la geocodificación directa, la geocodificación inversa y el autocompletado como totalmente terminados y con precisión verificada: los datos de direcciones en concreto varían enormemente por región en cuanto a lo bien que se mantienen, y una afirmación rotunda sobre ellos merece más escrutinio del que la propia afirmación suele invitar a hacer.
La antigüedad de un conjunto de datos no es un defecto en sí misma. Un conjunto de datos bien mantenido de hace cinco años que se ha mantenido actualizado es más fiable que uno nuevo que no volverá a revisarse hasta el próximo rediseño. Lo que importa es si un proveedor trata el mantenimiento de los datos como una obligación continua o como un proyecto único que se dio por terminado cuando la página de marketing se publicó. La forma honesta de juzgarlo no es el anuncio de lanzamiento. Es lo que hace un proveedor, discretamente, en los años siguientes.