Qué exigen realmente los datos de ubicación "en tiempo real"
"En tiempo real" se usa como sinónimo de rápido. Lo que debería significar es que la respuesta refleja el estado actual del mundo, no la foto del trimestre pasado.
Etiqueta
#api-design
Cómo tratamos los resultados nulos y de baja confianza
Cuando una consulta realmente no se puede resolver de forma fiable, no devolver nada es mejor respuesta que devolver una suposición disfrazada de hecho. Este es el razonamiento detrás de esa decisión.
Por qué los datos de elevación se tratan como algo secundario
Los datos de elevación rara vez tienen su propia línea en una página de precios, y esa ausencia dice algo real sobre la seriedad con la que se desarrollan.
Argumentos en contra de cobrar más por los métodos de autenticación básicos
Una cabecera, un token bearer y un parámetro de consulta autentican una solicitud de la misma manera. Cobrar más por uno de ellos es cobrar por una preferencia, no por una funcionalidad.
Diferencias en los límites de frecuencia que debes esperar al cambiar de proveedor
Los límites de frecuencia varían entre proveedores en su estructura, no solo en su cifra. Esto es lo que debes comprobar antes de dar por hecho que tu lógica actual sigue siendo válida.
Por qué preferimos responder con un error antes que con una suposición equivocada
Una respuesta equivocada que parece segura es peor que un fallo honesto. Un error te dice que revises algo. Una suposición equivocada y segura te dice que no pasa nada.
Migrar una integración del lado del servidor sin tocar el cliente
Una migración de geocodificación del lado del servidor a menudo puede ser invisible para las aplicaciones cliente que dependen de ella. Así puedes diseñarla de esa manera.
Por qué los niveles de precios por país son una mala idea
Cobrar más por consultar una dirección en un país que en otro convierte la propia geografía en una palanca de precios en lugar de tratarla como datos corrientes que hay que servir.
Argumentos para tratar las consultas de códigos postales como algo de primer nivel
Un endpoint de códigos postales con un precio y una documentación de segunda categoría también acabará desarrollado como algo de segunda categoría. Tomárselo en serio empieza por tratarlo igual que al resto.
En qué sigue fallando este sector con la adopción de IPv6
Una API de consulta de IP que todavía trata IPv6 como un caso límite menor está tratando discretamente como algo secundario una parte creciente del tráfico real de internet.
Por qué deberían existir tanto cuotas por cuenta como cuotas por red
Una cuota por cuenta controla quién eres. Una cuota por red controla de dónde viene realmente tu tráfico. Un sistema serio necesita ambas.
Un formato de error más limpio en todos los endpoints
Todos los endpoints devuelven ahora los errores en un formato único y coherente, lo que facilita detectar, registrar y gestionar los fallos desde el código.
Por qué las API que solo usan webhooks excluyen discretamente a quienes trabajan por lotes
Un webhook funciona bien para una solicitud cada vez. Funciona mal para un script que solo quiere enviar mil consultas y esperar mil respuestas.
Por qué publicamos nuestros códigos de error en lugar de ocultarlos
Un código de error sin documentar convierte cada solicitud fallida en un juego de adivinanzas. Publicar la lista es algo pequeño que ahorra tiempo real de depuración.
Por qué el precio por lotes debería ser igual al precio por solicitud individual
Mil consultas enviadas de una en una y mil consultas enviadas en un lote suponen la misma cantidad de trabajo. El precio no debería depender de cómo se empaquetaron.
Argumentos a favor de un versionado de API aburrido y estable
Una nueva versión de API emocionante es un proyecto de migración para todos los que dependen de ella. Un versionado aburrido y estable es una ventaja, no una falta de ambición.
Por qué no empezamos creando un SDK para el navegador
Un SDK para el navegador de una consulta del lado del servidor sobre todo traslada tu clave de API a un lugar donde el navegador del visitante puede verla. No es una comodidad que valga la pena tener.
Lo que resuelve la limitación de frecuencia por red que los límites por clave no resuelven
Un límite solo por clave da por hecho que una clave equivale a un usuario. Limitar la frecuencia por red cierra el resquicio por el que esa suposición deja de cumplirse sin que nadie lo note.
Los códigos postales merecen más respeto del que reciben
Las consultas de códigos postales se tratan como una utilidad menor al lado de la geocodificación, pero tienen una estructura real y una variación regional real que merecen el mismo cuidado.
Por qué la calidad de la documentación importa más que el número de funciones
Una función que no sabes cómo usar es como si no existiera. La documentación no es un coste de soporte, es parte del propio producto.
El coste silencioso de la dependencia del proveedor
La dependencia del proveedor rara vez aparece como una sola mala decisión. Aparece como cien pequeñas decisiones que, sin que se note, hacen que irse cueste mucho más que quedarse.
Los límites de frecuencia deberían estar documentados, no descubrirse
Descubrir tu límite de frecuencia por un error 429 en producción no es documentación. Es un ticket de soporte que nunca debería haber hecho falta.
Por qué contamos las solicitudes masivas por elemento y no por llamada
Una llamada por lotes con mil direcciones sigue haciendo mil consultas distintas. Contarla como una sola solicitud solo ocultaría a dónde fue realmente el uso.
Argumentos en contra de los formatos de respuesta propietarios
Un nombre de campo propietario o un modelo de objetos a medida no le ahorra nada al proveedor y más adelante le cuesta al cliente reescribir su código. Un JSON sencillo y predecible no es una función que falte.
En qué se equivoca la facturación por producto sobre cómo se usan las API
Las aplicaciones reales combinan geocodificación, consultas de IP y llamadas de zona horaria en un mismo flujo de solicitud. Facturarlas como productos separados ignora cómo se usan juntas.
Los datos abiertos de zonas horarias no deberían ser una función premium
Las consultas de zona horaria se basan en una fuente de datos pública y mantenida activamente. Cobrar un recargo premium aparte por esa consulta no refleja un coste adicional real.
Por qué los hosts compatibles importan más que un nuevo SDK
Un SDK te pide confiar en la biblioteca cliente de una empresa durante toda la vida de tu proyecto. Un host compatible te pide cambiar una línea de configuración.
Por qué fijamos el precio por solicitud y no por usuario
Un precio por solicitud se corresponde con lo que realmente cuesta operar una API. El precio por usuario mide la plantilla, no el uso, y el tráfico de geocodificación rara vez sigue ninguna de las dos cosas.