My Geocode

Migration

Migrer depuis ipstack

· 3 min de lecture · My Geocode · #ipstack#géolocalisation-ip#migration#compatibilité#api

ipstack s'authentifie avec un paramètre de requête access_key et renvoie une réponse JSON avec des champs comme type (ipv4 ou ipv6), continent_code, latitude, longitude et, sur les offres supérieures, un objet imbriqué connection qui contient les informations sur le système autonome et le FAI séparément des champs de premier niveau. Cette structure connection imbriquée est un peu plus élaborée que les formats plus plats de certains concurrents, ce qui convient aux applications qui veulent traiter les informations sur le FAI et le réseau comme un regroupement logique à part plutôt que mélangées aux champs de localisation.

Migrer ce type de structure imbriquée demande un peu plus de soin qu'une réponse plate, simplement parce que l'arborescence de la réponse compte davantage d'endroits où un nom de champ pourrait différer. Il vaut la peine de tester spécifiquement les chemins imbriqués, et pas seulement les champs de premier niveau, avant de considérer une migration comme terminée.

L'hôte compatible ipstack de My Geocode reproduit la structure complète, y compris les champs type, continent_code, latitude et longitude et l'objet imbriqué connection, seul le texte relatif aux droits d'auteur, aux conditions et à la confidentialité étant modifié. Les détails de référence se trouvent sur /compatibility/ipstack/. Le code qui lit response.connection.isp ou response.type devrait obtenir le même format une fois dirigé vers le nouvel hôte avec une nouvelle clé.

Comme les recherches d'IP fonctionnent entièrement de bout en bout chez My Geocode, les résultats sont ici concrets et pas seulement décrits dans leur format. Une recherche pour une adresse donnée renvoie en direct le pays, la région, la ville, les coordonnées et les informations de connexion, vérifiés auprès d'une couche de cache qui maintient la géolocalisation IP à jour plutôt que de dépendre de mises à jour par lots peu fréquentes.

Remarques de migration spécifiques aux intégrations ipstack :

  • Le paramètre de requête access_key correspond directement à notre option de paramètre de requête, ou vous pouvez passer à un en-tête X-API-Key, à Authorization: Bearer ou à l'authentification HTTP Basic au cours de la même migration si vous préférez changer de mode d'authentification en même temps
  • Des champs supplémentaires facultatifs (altitude le cas échéant, informations sur les menaces IP, informations réseau plus détaillées) sont disponibles via mg_extras=1 ou un en-tête X-MG-Extras, en complément du format standard sans en remplacer aucune partie
  • Si votre intégration vérifie les champs security pour la détection de proxy ou de menaces, ces valeurs précises font partie des extras optionnels et non de la réponse de compatibilité de base : vérifiez donc de quels champs votre code dépend réellement avant de supposer une parité complète

Côté tarifs, 2 500 requêtes par jour sont gratuites sans aucune clé, et chaque clé dispose de ses propres 2 500 requêtes gratuites par jour, comptées par réseau. Au-delà, le crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois s'appliquent uniformément, chaque endpoint, y compris cet hôte de compatibilité, étant facturé au même prix. Pour les applications qui utilisent l'objet connection d'ipstack comme un regroupement de données distinct dans leurs propres modèles internes, ce regroupement est conservé tel quel, ce qui préserve le code en aval, les tableaux de bord et les entrepôts de données construits sur cette structure.

Plus d'articles sur la migration