Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pourquoi nous préférons répondre par une erreur plutôt que par une mauvaise estimation
Une API qui renvoie toujours quelque chose, même pour une requête à laquelle elle ne peut pas bien répondre, paraît plus performante en surface qu'une API qui renvoie parfois une erreur claire à la place. Cette impression est trompeuse. Une réponse qui devine un résultat au lieu d'admettre son incertitude n'est pas plus utile. Elle est plus dangereuse, précisément parce qu'elle ressemble exactement à une réponse assurée et correcte et ne donne à l'appelant aucun signal l'incitant à vérifier avant d'agir.
Nous préférons renvoyer une erreur claire, ou une réponse qui indique clairement une correspondance partielle ou peu fiable, plutôt que de substituer en silence une meilleure supposition déguisée en réponse normale. Cela compte surtout pour le géocodage direct, le géocodage inverse et la saisie semi-automatique, exactement les endpoints où une adresse partielle ou ambiguë peut inciter un système à renvoyer la correspondance plausible la plus proche au lieu de reconnaître que l'entrée n'a pas été résolue proprement. Une correspondance plausible la plus proche présentée comme un résultat normal est la façon la plus probable pour que de mauvaises données de localisation se retrouvent intégrées dans une expédition, une vérification de zone de service ou une fiche client, car rien dans la réponse ne signale une quelconque incertitude.
C'est aussi l'une des raisons pour lesquelles nous sommes délibérément prudents avant d'annoncer un chiffre de précision précis et vérifié pour le géocodage et la saisie semi-automatique, plutôt que d'affirmer qu'il s'agit de fonctionnalités entièrement terminées et éprouvées. Un système assez sûr de lui pour publier un chiffre de précision précis doit être tout aussi sûr de ce qui se passe pour les entrées que ce chiffre ne couvre pas, et la réponse honnête, pour tout système de géocodage, inclut une part d'adresses qui devraient revenir non résolues ou ambiguës au lieu d'être forcées dans une réponse.
Une réponse d'erreur a un coût sur le moment : elle oblige l'application appelante à gérer un cas d'échec au lieu de toujours recevoir un objet propre, et elle peut sembler offrir une moins bonne expérience développeur en surface, puisqu'une supposition qui s'avère juste ressemble exactement à une réponse sans erreur et qu'une supposition qui s'avère fausse aussi, jusqu'à ce que quelqu'un en aval s'en aperçoive. C'est exactement là le problème. Une supposition et une réponse correcte sont indiscernables de l'extérieur, et c'est précisément pourquoi un système incapable de faire la différence en interne ne devrait pas masquer cet écart en choisissant l'une et en la présentant comme certaine.
Nous pensons que cette préférence, un échec clair plutôt qu'une supposition assurée, devrait être une attente de base pour toute API de données, pas seulement la nôtre. Un appelant peut construire une vraie gestion des erreurs autour d'un système qui dit la vérité sur ce qu'il ne sait pas. Aucun appelant ne peut construire une gestion des erreurs fiable autour d'un système qui répond toujours, car il n'existe aucun moyen de distinguer les requêtes auxquelles il a vraiment bien répondu de celles qu'il a devinées en silence et pour lesquelles il est tombé du mauvais côté.