Die Kladde kann Mails schicken, Termine abgleichen, Dateien ablegen und Meldungen senden. Im Betrieb zeigt sich, ob sie das auch an einem schlechten Tag tut: wenn Graph drosselt, ein Dienst antwortet, ohne dass man weiß, ob die Anfrage ankam, ein Recht fehlt oder ein Geheimnis abläuft. Diese Lektion macht die Aufrufe der Lektionen W4.2.1 bis W4.3.1 betriebsfest. Sie wiederholt nicht, was K2 und K3 lehren: die Regeln für Wiederholungen und den unklaren Ausgang (Lektion 2.8.3), die Outbox (Lektion 2.8.4), Tests ohne Netz (Lektion 2.8.1), die verwaltete Identität (Lektion 3.3.1), die Wiederholungs-Handler (Lektion 3.9.2) und die Telemetrie (Lektionen 3.4.1 bis 3.4.5). Sie wendet sie auf Graph an.

Zum Stand dieser Lektion. Nichts davon wurde gegen einen Microsoft-365-Mandanten ausgeführt: nicht gegen einen Mandanten ausgeführt. Anfragen, Antworten, Befehle und Berechtigungen stammen aus Seiten von Microsoft Learn (am Ende unter „Weiterlesen“); was sie nicht beantworten, steht als „offen“ da. Was einen Mandanten braucht, läuft nur in einem Testmandanten, nie in einem Produktivmandanten, und jede solche Übung hat einen Teil, der ohne Mandanten läuft.

Drosselung: 429, 503 und Retry-After

Graph begrenzt, wie viel eine Anwendung auf einmal verlangen darf. Überschreitet sie eine Schwelle, begrenzt der Dienst weitere Anfragen dieser Anwendung für eine Zeit, antwortet mit 429 Too Many Requests, die Anfragen scheitern, und die Antwort nennt eine vorgeschlagene Wartezeit im Kopf Retry-After. Die Schwellen hängen von der Art und Zahl der Anfragen ab: Schreiben wird eher gedrosselt als Lesen, und es kann sein, dass Schreibaufrufe gedrosselt sind, Leseaufrufe aber nicht. Die häufigsten Ursachen laut Microsoft sind viele Anfragen aller Anwendungen eines Mandanten und viele Anfragen einer Anwendung über alle Mandanten. Die Antwort sieht so aus (das Beispiel von Microsoft; der Zeitstempel ist erfunden):

http
HTTP/1.1 429 Too Many Requests
Retry-After: 10

{
  "error": {
    "code": "TooManyRequests",
    "innerError": { "code": "429", "date": "2020-08-18T12:51:51", "message": "Please retry after", "request-id": "94fb3b52-452a-4535-a601-69e0a90e3aa2", "status": "429" },
    "message": "Please retry again later."
  }
}

Was Microsoft zum Umgang rät, in der Reihenfolge, in der die Kladde es umsetzt:

  1. Auf 429 reagieren, nicht auf den Text: Warten Sie die Sekunden aus Retry-After, wiederholen Sie dann. Kommt wieder 429, sind Sie noch gedrosselt: weiter mit dem Rat des Dienstes warten. Der Dienst zählt weiter mit, solange ein Client gedrosselt ist; sofortige Wiederholungen verschlimmern es, denn alle Anfragen gehen auf Ihr Konto.
  2. Fehlt Retry-After, empfiehlt Microsoft eine Wiederholung mit wachsender Pause (exponentielles Backoff).
  3. 503 Service Unavailable behandeln Sie ähnlich (Wartezeit, oft mit Retry-After), und neue Wiederholungen schicken Sie über eine neue HTTP-Verbindung. Die Seite „Best practices“ sagt das ausdrücklich.
  4. Weniger fragen: weniger Vorgänge je Anfrage, seltener fragen. Wer ständig abfragt, ob sich etwas geändert hat, oder Ressourcen regelmäßig vollständig durchsucht, wird eher gedrosselt. Dafür gibt es Delta-Abfragen und Änderungsbenachrichtigungen (Lektion W4.2.3).
  5. Große Mengen gehören nicht in die REST-Aufrufe: Microsoft verweist dafür auf Microsoft Graph Data Connect, das nicht den Drosselgrenzen unterliegt. Das ist kein Teil dieses Kurses.

Die Grenzwerte je Dienst stehen auf einer eigenen Seite („Service-specific limits“). Diese Lektion nennt keine Zahl daraus, weil sie nicht gelesen wurde.