Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Envía tu clave de API de tres formas distintas (y por qué importa)
No todas las herramientas que se comunican con una API gestionan la autenticación de la misma manera, por eso la API acepta una clave mediante más de un mecanismo en lugar de obligar a pasarlo todo por un único nombre de cabecera.
La cabecera X-API-Key
Es la opción más directa, una cabecera dedicada que no lleva nada más que la clave.
GET /v1/forward?q=Baker+Street
X-API-Key: mg_live_examplekey123Authorization: Bearer
Algunos clientes HTTP y gateways de API ya están configurados para adjuntar un token bearer a cada solicitud saliente, y usar ese mecanismo significa que no necesitas añadir una segunda cabecera específica de la API junto a él.
GET /v1/forward?q=Baker+Street
Authorization: Bearer mg_live_examplekey123Autenticación HTTP Basic
Las herramientas más antiguas, y algunas integraciones entre servidores creadas para otros proveedores, esperan las credenciales como autenticación HTTP Basic. La clave va como nombre de usuario, con la contraseña en blanco.
GET /v1/forward?q=Baker+Street
Authorization: Basic bWdfbGl2ZV9leGFtcGxla2V5MTIzOg==Un parámetro de consulta, para todo lo demás
Cuando una herramienta no te da ningún control sobre las cabeceras, como una prueba rápida en la barra de direcciones del navegador o un cliente que solo admite configuración basada en la URL, la clave también puede enviarse como parámetro de consulta directamente en la solicitud.
GET /v1/forward?q=Baker+Street&key=mg_live_examplekey123Por qué la elección importa en la práctica
Una clave enviada como parámetro de consulta acaba en los registros del servidor, en el historial del navegador y en las cabeceras Referer con más facilidad que una enviada en una cabecera de la solicitud, así que prefiere un método basado en cabeceras siempre que el código que hace la llamada tenga algún control sobre ello. Los cuatro métodos funcionan exactamente igual con todos los endpoints y todos los hosts de compatibilidad, así que cambiar de uno a otro más adelante, por ejemplo al pasar un script de una prueba en el navegador a una integración de backend en condiciones, no cambia nada en cómo se contabilizan la cuota o el crédito de la clave.
Uso en los hosts de compatibilidad
Cada uno de los 17 hosts de compatibilidad acepta las credenciales con el mismo estilo que usaba el proveedor original, así que un script escrito según la convención de autenticación de otro proveedor suele seguir funcionando después de apuntarlo al host de compatibilidad correspondiente de My Geocode, sin reescribir cómo se envía la clave. Consulta la página de compatibilidad para ver la lista de hosts y el estilo de credenciales que espera cada uno.
Un error que conviene evitar
Probar un script con la clave como parámetro de consulta y dejarlo así en producción es un hábito fácil de adquirir, ya que el parámetro de consulta suele ser la forma más rápida de conseguir que funcione una primera solicitud. Pasa a un método basado en cabeceras, X-API-Key o Authorization, antes de que el script se acerque al tráfico de producción o se suba a un repositorio compartido, ya que una clave visible en una URL tiene muchas más probabilidades de acabar donde no querías, como el registro de un proxy o el archivo de historial del navegador en un equipo compartido.
Sin diferencia de coste
Ninguno de estos métodos cambia cómo se factura una solicitud. Cada solicitud con la clave sigue contando igual para sus 2.500 solicitudes gratuitas al día y, a partir de ahí, contra el crédito prepago o un paquete Unlimited.
Elegir el método de autenticación adecuado consiste sobre todo en adaptarse a lo que ya admite la herramienta que hace la llamada, no en el rendimiento ni en el coste. Tienes todos los detalles en la documentación de autenticación.