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.
Contre la facturation supplémentaire des méthodes d'authentification de base
L'authentification est l'un des aspects les plus banals de l'utilisation d'une API, et c'est précisément le genre de détail banal qui se retrouve réservé à une formule tarifaire plus souvent qu'il ne le devrait. Certains fournisseurs réservent certaines méthodes d'authentification, l'authentification HTTP Basic ou un jeton Bearer, aux formules payantes supérieures, tandis qu'une formule inférieure ne prend en charge qu'un seul format d'en-tête bien précis. La différence de coût technique entre la validation d'un style d'authentification et d'un autre est quasi nulle. Ce qui diffère, c'est la commodité de chacun pour le code existant d'un client donné, ce qui n'a rien à voir avec le montant qu'il devrait payer pour utiliser l'API.
Nous acceptons une clé sous forme d'en-tête X-API-Key, d'en-tête Authorization Bearer, d'authentification HTTP Basic avec la clé comme nom d'utilisateur, ou de paramètre de requête, sur chaque hôte, sans frais supplémentaires pour aucune de ces méthodes. Quel que soit le modèle qui convient déjà à votre code existant, quelle que soit la bibliothèque ou la convention interne que votre équipe utilise déjà pour d'autres API, il est très probablement déjà pris en charge, sans avoir à restructurer quoi que ce soit simplement pour correspondre à un format que nous aurions préféré.
La logique qui consiste à réserver des méthodes d'authentification à certaines formules ne tient pas vraiment au coût. Elle tient à la différenciation des formules pour elle-même : trouver des fonctionnalités à réserver à un client qui paie davantage, même des fonctionnalités qui ne coûtent rien de plus à fournir, simplement parce que davantage de fonctionnalités verrouillées derrière une formule supérieure la font paraître plus intéressante dans un tableau comparatif. Les méthodes d'authentification sont une cible facile, car en prendre en charge plusieurs demande réellement peu d'efforts au fournisseur et s'avère réellement pratique pour le client, ce qui fait de leur restriction une décision purement commerciale plutôt qu'une décision fondée sur une véritable différence de coût.
Nous pensons que ce type de restriction pénalise discrètement les développeurs pour une décision qui n'a rien à voir avec la valeur qu'ils tirent réellement des données. Une équipe dont les outils utilisent par défaut des jetons Bearer ne devrait pas payer plus qu'une équipe dont les outils utilisent par défaut un en-tête personnalisé, alors que les deux équipes effectuent exactement la même recherche et reçoivent exactement la même réponse. La valeur du produit, c'est la réponse. La méthode d'authentification, c'est de la plomberie, et la plomberie ne devrait pas avoir un prix qui dépend du tuyau qui s'adapte à votre mur existant.
Il y a ici un principe plus large qui dépasse l'authentification : les fonctionnalités qui ne coûtent rien de plus au fournisseur ne devraient pas devenir des frontières artificielles entre formules simplement parce qu'elles peuvent l'être. Une structure de formules fondée sur de vraies différences de coût, comme le volume de requêtes, est défendable. Une structure de formules gonflée de commodités peu coûteuses réservées aux clients qui paient plus existe surtout pour que la page de tarifs paraisse plus différenciée que le produit sous-jacent ne l'est réellement.