Microsoft Graph Developer Proxy - un proxy pour tester l’API MS Graph en local

Pour les personnes qui doivent développer et maintenir des applications liées aux services cloud Microsoft 365 fournis par Microsoft, il est pratiquement impossible d’éviter la Microsoft Graph API. Pour ceux qui ne la connaissent pas, il s’agit d’une API RESTful permettant d’accéder de manière unifiée à toutes les ressources cloud proposées par Microsoft. Microsoft fournit également le Graph SDK dans plusieurs langages pour faciliter l’utilisation de cette API.

Le problème, c’est qu’il était particulièrement difficile de tester les parties qui utilisent cette API. Je l’ai surtout ressenti dans les cas où la Graph API applique une rate limit et renvoie une réponse 429 Too Many Requests. Lorsqu’on utilise le Graph SDK, il effectue bien des tentatives automatiques en cas de code de réponse 429 dû au throttling, en se basant sur la valeur Retry-After de l’en-tête de réponse. Mais dans certains cas, il valait mieux échouer rapidement sans réessayer, ou appliquer une politique différente de celle par défaut. Le souci, c’est qu’il n’existait pas vraiment de moyen de tester ce type de scénario dans un environnement de développement. J’ai ainsi déjà eu l’expérience de me rendre compte, seulement après le déploiement initial du produit, qu’il fallait modifier la politique de retry des requêtes du Graph SDK par rapport au comportement par défaut, puis de corriger cela dans une version ultérieure.

Microsoft était partiellement conscient de ce problème et avait ajouté une fonctionnalité permettant de mocker un cas de réponse 429 en ajoutant le paramètre test429=true à l’URL de la requête API. Mais cette solution avait la limite de ne fonctionner que sur les endpoints liés à SharePoint et OneDrive.
https://pnp.github.io/blog/post/…

C’est dans ce contexte qu’un outil bienvenu est finalement apparu au début de la nouvelle année : Microsoft Graph Developer Proxy.
C’est un outil capable de mocker différents types de réponses renvoyées par la Graph API, ainsi que de reproduire facilement diverses erreurs ou situations de throttling. Et en prime, les requêtes testées ne quittent pas l’environnement de développement local. Le projet en est encore à un stade précoce, mais une version officielle devrait sortir dans le courant de l’année. Pour les personnes qui travaillent dans ce domaine, c’est clairement l’arrivée d’un outil très pratique.

[kunggom]

À titre indicatif, avant même la sortie de cet outil, il n’était pas totalement impossible de simuler une situation où l’API Graph renvoie un 429. Il existait notamment des méthodes utilisant des outils comme Fiddler. Mais c’était assez peu pratique.

D’après le README, l’outil présenté ci-dessus a été créé l’an dernier (2022) par Waldek Mastykarz lors d’un hackathon. Et dans un ancien billet de blog de cette personne (2018), on trouve une présentation de la manière de simuler une situation où l’API SharePoint renvoie un 429 avec Fiddler.
https://blog.mastykarz.nl/simulating-throttling-sharepoint/