Microsoft Graph Developer Proxy – Ein Proxy zum lokalen Testen der MS Graph API

Für alle, die Anwendungen entwickeln und warten müssen, die mit den von Microsoft bereitgestellten Microsoft-365-Cloud-Diensten zu tun haben, gibt es etwas, dem man kaum ausweichen kann: die Microsoft Graph API. Für alle, die nicht genau wissen, was das ist, hier eine kurze Einführung: Es handelt sich um eine RESTful API, mit der sich auf sämtliche von Microsoft bereitgestellten Cloud-Ressourcen einheitlich zugreifen lässt. Microsoft stellt für die komfortable Nutzung dieser API in einigen Sprachen auch ein Graph SDK bereit.

Das Problem war, dass sich die Teile, die diese API verwenden, nur schwer testen ließen. Besonders deutlich wurde mir das in Fällen, in denen die Graph API wegen eines Rate Limits mit 429 Too Many Requests antwortete. Wenn man das Graph SDK verwendet, wird bei einem 429-Antwortcode durch Throttling zwar anhand des Retry-After-Werts im Response-Header automatisch erneut versucht, die Anfrage auszuführen. In manchen Fällen war es jedoch besser, ohne Wiederholungsversuch schnell fehlschlagen zu lassen oder eine andere Policy als die Standardvorgabe anzuwenden. Das Problem war, dass es in der Entwicklungsumgebung kaum eine praktikable Möglichkeit gab, solche Fälle zu testen. Deshalb habe ich erst nach dem initialen Produkt-Release gemerkt, dass die Request-Retry-Policy des Graph SDK vom Standardwert abweichen sollte, und dies dann erst in einer späteren Version korrigiert.

Microsoft war sich dieses Problems offenbar bis zu einem gewissen Grad bewusst und hat eine Funktion ergänzt, mit der sich Fälle mit dem 429-Antwortcode mocken lassen, wenn man der API-Request-URL den Parameter test429=true hinzufügt. Die Einschränkung dabei war jedoch, dass dies ausschließlich bei SharePoint-/OneDrive-bezogenen Endpunkten funktioniert.
https://pnp.github.io/blog/post/…

In dieser Situation ist nun endlich zu Jahresbeginn ein willkommenes Tool erschienen: der Microsoft Graph Developer Proxy.
Damit lassen sich verschiedenste von der Graph API zurückgegebene Response-Werte mocken und unterschiedliche Fehler oder Throttling-Situationen bequem nachstellen. Ein zusätzlicher Vorteil ist, dass die zu testenden Requests die lokale Entwicklungsumgebung nicht verlassen. Das Projekt befindet sich zwar noch in einem frühen Entwicklungsstadium, soll aber noch im Laufe dieses Jahres offiziell veröffentlicht werden. Zumindest für alle, die in diesem Bereich arbeiten, ist das wirklich ein sehr praktisches neues Tool.

[kunggom]

Zur Info: Schon bevor dieses Tool erschien, gab es durchaus Möglichkeiten, eine Situation zu simulieren, in der bei der Graph API ein 429 auftritt. Man konnte dafür etwa Tools wie Fiddler verwenden. Allerdings war das ziemlich umständlich.

Laut README wurde das oben vorgestellte Tool von Waldek Mastykarz bei einem Hackathon im vergangenen Jahr (2022) entwickelt. In einem älteren Blogbeitrag von ihm aus dem Jahr 2018 zeigt er, wie man mit Fiddler eine Situation nachstellen kann, in der bei der SharePoint API ein 429 auftritt.
https://blog.mastykarz.nl/simulating-throttling-sharepoint/