Ce qu'exigent réellement des données de localisation « en temps réel »
« Temps réel » est employé comme synonyme de « rapide ». Cela devrait signifier que la réponse reflète l'état actuel du monde, et non un instantané du trimestre dernier.
Tag
#conception-d'api
Comment nous traitons les résultats nuls et peu fiables
Lorsqu'une requête ne peut réellement pas être résolue de manière fiable, ne rien renvoyer est une meilleure réponse que renvoyer une supposition présentée comme un fait. Voici le raisonnement derrière ce choix.
Pourquoi les données d'altitude sont traitées comme secondaires
Les données d'altitude ont rarement leur propre ligne sur une page de tarifs, et cette absence en dit long sur le sérieux avec lequel elles sont réellement construites.
Contre la facturation supplémentaire des méthodes d'authentification de base
Un en-tête, un jeton bearer et un paramètre de requête authentifient tous une requête de la même façon. Facturer davantage l'un d'eux revient à faire payer une préférence, pas une fonctionnalité.
Les différences de limite de débit à prévoir quand vous changez de fournisseur
Les limites de débit diffèrent d'un fournisseur à l'autre dans leur structure, pas seulement dans leurs chiffres. Voici ce qu'il faut vérifier avant de supposer que votre logique actuelle s'applique toujours.
Pourquoi nous préférons répondre par une erreur plutôt que par une mauvaise estimation
Une mauvaise réponse qui a l'air sûre d'elle est pire qu'un échec honnête. Une erreur vous dit de vérifier quelque chose. Une mauvaise estimation affichée avec assurance vous dit que tout va bien.
Migrer une intégration côté serveur sans toucher au client
Une migration du géocodage côté serveur peut souvent rester invisible pour les applications clientes qui en dépendent. Voici comment la concevoir ainsi.
Pourquoi une tarification par pays est une mauvaise idée
Facturer plus cher la recherche d'une adresse dans un pays que dans un autre fait de la géographie elle-même un levier tarifaire, au lieu de simples données ordinaires à servir.
Pour que la recherche de code postal soit traitée comme une fonctionnalité à part entière
Un endpoint de code postal tarifé et documenté comme un élément secondaire sera aussi construit comme tel. Le prendre au sérieux commence par le traiter sur un pied d'égalité.
Ce que le secteur comprend encore mal à propos de l'adoption de l'IPv6
Une API de recherche d'IP qui traite encore l'IPv6 comme un cas marginal traite discrètement comme secondaire une part croissante du trafic internet réel.
Pourquoi il faut à la fois des quotas par compte et des quotas par réseau
Un quota par compte suit qui vous êtes. Un quota par réseau suit d'où vient réellement votre trafic. Un système sérieux a besoin des deux.
Un format d'erreur plus clair sur tous les endpoints
Chaque endpoint renvoie désormais les erreurs dans un format unique et cohérent, ce qui rend les échecs plus faciles à détecter, à journaliser et à traiter par programme.
Pourquoi les API uniquement à webhooks excluent discrètement les utilisateurs de traitements par lots
Un webhook fonctionne bien pour une requête à la fois. Il fonctionne mal pour un script qui veut simplement envoyer mille recherches et attendre mille réponses.
Pourquoi nous publions nos codes d'erreur au lieu de les cacher
Un code d'erreur non documenté transforme chaque requête échouée en jeu de devinettes. Publier la liste est un petit geste qui fait gagner un temps de débogage réel.
Pourquoi le tarif des lots devrait être le même que celui des requêtes unitaires
Mille recherches envoyées une par une et mille recherches envoyées en lot représentent la même quantité de travail. Le prix ne devrait pas dépendre de la façon dont elles sont regroupées.
Pour un versionnage d'API ennuyeux et stable
Une nouvelle version d'API enthousiasmante est un projet de migration pour tous ceux qui en dépendent. Un versionnage ennuyeux et stable est une fonctionnalité, pas un manque d'ambition.
Pourquoi nous n'avons pas commencé par un SDK pour navigateur
Un SDK pour navigateur destiné à une recherche côté serveur ne fait surtout que déplacer votre clé d'API à un endroit où le navigateur d'un visiteur peut la voir. Ce n'est pas une commodité qui vaille la peine.
Ce que la limitation de débit par réseau résout et que les limites par clé ne résolvent pas
Une limite par clé seule suppose qu'une clé correspond à un utilisateur. La limitation de débit par réseau comble la faille qui apparaît discrètement quand cette hypothèse ne tient plus.
Les codes postaux méritent plus de considération qu'ils n'en reçoivent
La recherche de code postal est traitée comme un utilitaire mineur à côté du géocodage, mais elle a une vraie structure et de vraies variations régionales qui méritent le même soin.
Pourquoi la qualité de la documentation compte plus que le nombre de fonctionnalités
Une fonctionnalité dont on ne comprend pas comment l'utiliser pourrait tout aussi bien ne pas exister. La documentation n'est pas un coût d'assistance, elle fait partie du produit lui-même.
Le coût discret de la dépendance à un fournisseur
L'enfermement se manifeste rarement par une seule mauvaise décision. Il se manifeste par une centaine de petites décisions qui, discrètement, rendent le départ bien plus coûteux que le simple fait de rester.
Les limites de débit doivent être documentées, pas découvertes
Découvrir votre limite de débit par une erreur 429 en production, ce n'est pas de la documentation. C'est un ticket d'assistance qui n'aurait jamais dû être nécessaire.
Pourquoi nous comptons les requêtes groupées par élément et non par appel
Un appel par lot de mille adresses effectue toujours mille recherches distinctes. Le compter comme une seule requête ne ferait que masquer où est réellement passée la consommation.
Contre les formats de réponse propriétaires
Un nom de champ propriétaire ou un modèle d'objet sur mesure ne fait rien gagner au fournisseur et coûte au client une réécriture plus tard. Un JSON simple et prévisible n'est pas une fonctionnalité manquante.
Ce que la facturation par produit comprend mal à l'usage réel des API
Les vraies applications combinent géocodage, recherches d'IP et appels de fuseau horaire dans un même parcours de requête. Les facturer comme des produits séparés ignore la façon dont ils sont utilisés ensemble.
Les données ouvertes de fuseau horaire ne devraient pas être une fonctionnalité premium
Les recherches de fuseau horaire reposent sur une source de données publique et activement maintenue. Facturer un supplément premium pour cette recherche ne correspond à aucun coût supplémentaire réel.
Pourquoi les hôtes compatibles comptent plus qu'un nouveau SDK
Un SDK vous demande de faire confiance à la bibliothèque cliente d'une seule entreprise pendant toute la durée de votre projet. Un hôte compatible vous demande de modifier une ligne de configuration.
Pourquoi nous facturons à la requête et non par utilisateur
Un prix à la requête correspond à ce que coûte réellement le fonctionnement d'une API. La tarification par utilisateur mesure l'effectif, pas la consommation, et le trafic de géocodage ne suit presque jamais l'un ou l'autre.