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 les API uniquement à webhooks excluent discrètement les utilisateurs de traitements par lots
Un webhook a du sens pour un événement dont vous ne pouvez pas prévoir le moment : un paiement validé, un changement de statut d'expédition, quelque chose qui se produit du côté du fournisseur et auquel votre système doit réagir dès que cela arrive. Il a beaucoup moins de sens comme seul moyen d'obtenir la réponse à une question que vous avez posée directement et à laquelle vous attendez une réponse directe, comme résoudre une adresse ou rechercher un fuseau horaire. Exiger un endpoint de webhook simplement pour recevoir le résultat d'une recherche synchrone reporte un vrai travail d'infrastructure sur un client qui voulait peut-être juste exécuter un script, attendre une réponse et passer à autre chose.
Cela devient un problème plus important précisément pour les traitements par lots et en masse. Un développeur qui exécute un script ponctuel pour résoudre une liste d'adresses issue d'un tableur ne veut pas mettre en place un récepteur de webhooks, gérer les nouvelles tentatives si son endpoint est brièvement injoignable et rattacher les charges utiles de webhook entrantes aux requêtes d'origine, tout cela pour obtenir des réponses qui auraient pu revenir directement dans la réponse à l'appel qui les demandait. Pour ce type de tâche, la livraison uniquement par webhook ajoute toute une couche d'infrastructure à une tâche qui devrait se résumer à une seule requête et une seule réponse.
Nous traitons les recherches, y compris par lots et en masse, comme synchrones par défaut : vous envoyez la requête, vous recevez directement la réponse, que cette requête contienne un élément ou mille. Utiliser un endpoint de traitement par lots n'exige en rien de mettre en place un récepteur public simplement pour collecter les résultats. Un script, une tâche cron ou un outil en ligne de commande ponctuel peut appeler l'endpoint et utiliser la réponse immédiatement, exactement comme pour une recherche unique.
La conception uniquement à webhooks découle généralement d'une architecture bâtie autour d'un traitement asynchrone du côté du fournisseur, où une grosse tâche par lots prend réellement un temps significatif à se terminer en interne, et où un webhook est vraiment la façon la plus naturelle de signaler la fin du traitement. C'est un modèle légitime pour certains types de traitements à grande échelle ou fortement mis en file d'attente. Cela devient un problème quand c'est la seule option proposée, ce qui force chaque cas d'usage, y compris ceux qui préféreraient simplement attendre un instant et obtenir directement une réponse, dans une architecture conçue pour une autre charge de travail, plus lente.
Nous ne sommes pas opposés à l'existence des webhooks comme option pour un travail réellement long ou asynchrone. Nous sommes opposés à ce qu'ils soient obligatoires pour des tâches qui n'ont aucun besoin d'être asynchrones. Un script qui veut envoyer mille recherches et recevoir mille réponses doit pouvoir faire exactement cela, en un seul appel et une seule réponse, sans d'abord construire une infrastructure pour recevoir un rappel pour une tâche qu'une requête synchrone aurait traitée tout aussi bien, avec beaucoup moins de code.