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.
Los datos abiertos de zonas horarias no deberían ser una función premium
La base de datos de zonas horarias de la IANA es pública. Se mantiene de forma abierta desde hace décadas y registra cada cambio de desfase, cada regla de horario de verano y cada modificación de fronteras que deciden los gobiernos. Casi todas las consultas serias de zona horaria de internet, incluida la nuestra, se basan en ese mismo conjunto de datos público. Así que, cuando una API cobra un precio premium aparte específicamente por las consultas de zona horaria, además de lo que ya cobra por la geocodificación, vale la pena preguntarse qué es exactamente lo que se paga con ese sobreprecio.
A veces la respuesta es legítima: tiempo de ingeniería dedicado a mantener precisa la correspondencia entre coordenadas y fronteras de zonas horarias a medida que esas fronteras cambian, e infraestructura para atender consultas a escala. Es un trabajo real y cuesta algo. Lo que es menos legítimo es tratar los datos de zonas horarias como una línea de producto aparte con su propio nivel de precios, muy por encima del coste marginal de una consulta, porque pueden incluirse en un flujo de trabajo que el cliente ya necesita y es menos probable que busque alternativas por separado.
Nosotros no separamos la zona horaria como un complemento premium. Es un endpoint más entre varios, con el mismo precio que cualquier otro: cubierto por la cuota diaria gratuita y, más allá de ella, facturado a los mismos 0,0001 € por solicitud que todo lo demás, o incluido en la misma clave Unlimited de 50 €. No hay un nivel aparte para la zona horaria ni un sobreprecio por preguntar qué hora es en unas coordenadas.
Las consultas de zona horaria importan más de lo que sugiere su nombre poco llamativo. Los sistemas de programación, las canalizaciones de registros, las plataformas de reservas y cualquier cosa que tenga que mostrar a un usuario la hora local correcta dependen de hacerlo bien. Si se hace mal, una invitación a una reunión llega con una hora de desfase, una marca de tiempo de un registro despista una investigación o una ventana de entrega promete la hora local equivocada. Este es exactamente el tipo de consulta que debería ser barata y aburrida, no una partida que aparece como un salto sorprendente en una factura.
Parte del motivo por el que en otros sitios las consultas de zona horaria se tratan como una función premium es que los cambios de horario de verano y las modificaciones de fronteras hacen que los datos subyacentes parezcan más complicados que unos códigos de país estáticos. Son datos realmente engorrosos de mantener. Pero engorroso de mantener no es lo mismo que caro de servir por solicitud, y el precio debería seguir esto último, no la complejidad de lo primero.
Cobrar un sobreprecio por los datos de zonas horarias también crea un mal incentivo a nivel de diseño de la API: los proveedores dejan de querer exponerlos directamente y empiezan a querer envolverlos en paquetes más grandes y caros, con la idea de que una función cuyo precio nadie puede comparar por separado es más fácil de encarecer. Creemos que el enfoque contrario genera más confianza. Haz que el endpoint sea simple, ponle el mismo precio que a todo lo demás y deja que los desarrolladores lo usen exactamente tanto como necesite su aplicación, sin hacer cálculos mentales sobre si esta consulta en concreto es de las caras.