Eine API-Bewertung sollte beantworten, ob ein Kunde die beabsichtigten Beweise zuverlässig abrufen kann, und nicht, ob eine Beispielanforderung HTTP 200 zurückgibt. Definieren Sie zuerst den Workflow: Exportieren Sie beispielsweise die erhaltenen Beweise eines Kunden aggregierte Berichte in ein privates Beweislager übertragen, ohne Seiten zu verlieren oder Mieter zu vermischen. Gehen Sie nicht davon aus, dass ein benanntes Produkt diese Schnittstelle anbietet, bis sein aktueller Vertrag überprüft wurde.
Stecken Sie den Vertrag und die Grenzen fest
Notieren Sie Anbieter, Endpunkt, API-Version, Authentifizierungsmethode, Mandantengrenze, Felder, Paginierungsregeln und dokumentierte Grenzwerte. Trennen Sie die Identität eines Berichts vom Zeitpunkt seines Eintreffens und dem Zeitraum, den er abdeckt. Geben Sie an, ob die API Rohberichte, normalisierte Zeilen oder abgeleitete Ergebnisse zurückgibt. Dabei handelt es sich um unterschiedliche Beweispopulationen, die unterschiedliche Abgleichsregeln erfordern.
GitHubs API-Versionsdokumentation veranschaulicht die explizite Versionsauswahl mit X-GitHub-Api-Version. Das ist ein konkretes Beispiel für die Versionierungspraxis und kein Beweis dafür, dass GitHub exportiert DMARC Berichte. Für eine tatsächliche Bewertung notieren Sie diese Details vor dem Test in einer überprüfbaren Vertragsnotiz. Dieses Handbuch stellt keinen Anbietervertrag, keine Endpunkt- oder Produktfunktionen bereit.
Testen Sie Herkunft und Felder
Behalten Sie für eine normalisierte Zeile den Melder, die Berichts-ID, den ursprünglichen Zeitraum, die Empfangszeit und den Fingerabdruck der Quelle bei, sofern verfügbar. Bewahren Sie das Originalartefakt unter genehmigten Aufbewahrungskontrollen auf. RFC 9990 ist die primäre Referenz für die Struktur des aggregierten Berichts. Ein praktisches JSON-Schema kann die gemeldeten Zählungen nicht in Beweise für zugestellte Nachrichten umwandeln oder Informationen wiederherstellen, die der Empfänger nie bereitgestellt hat.
Fragen Sie, wie der Dienst eine teilweise Erfassung, fehlerhafte Berichte, korrigierte Daten und fehlende Erfassungszeiträume darstellt. Eine stillschweigend übersprungene Seite kann eine plausible Metrik falsch machen. Fordern Sie ein Beispiel an, das bekannte Fehler enthält, und vergleichen Sie es mit unabhängig gezählten Eingaben, nicht nur mit einem anderen Bildschirm, der auf demselben Export basiert.
Trainieren Sie Fehlerpfade gezielt
Testen Sie ein mehrseitiges Ergebnis, ein leeres Ergebnis, eine doppelte Eingabe, zwei Datensätze mit gemeinsamem Zeitstempel, einen widerrufenen Berechtigungsnachweis, eine mandantenübergreifende Anfrage und einen vorübergehenden Fehler. Folgen Sie dokumentierten Fortsetzungslinks oder Cursorn. Für Ratenbegrenzung, Datensatzstatus, relevante Header und Wiederholungsrichtlinien. Best Practices von GitHub empfehlen, Ratenbegrenzungssignale zu respektieren und unkontrollierte Parallelität zu vermeiden; Genaue Grenzwerte gehören weiterhin zum eigentlichen Servicevertrag.
Angenommen, Seite eins wird gespeichert, Seite zwei schlägt jedoch fehl. Ein HTTP 200 für die erste Anfrage kann keinen vollständigen Export rechtfertigen; Behalten Sie den Teilstatus bei und nutzen Sie den vom Anbieter unterstützten Fortsetzungs- oder Neustartprozess. Unabhängig davon muss eine erfolgreich authentifizierte Anfrage für einen anderen autorisierten Testmieter dennoch abgelehnt werden, wenn dem Anrufer diese Berechtigung fehlt. Diese hypothetischen Fälle prüfen unterschiedliche Anforderungen: Vollständigkeit und Autorisierung.
Unterscheiden Sie bei einem Wiederholungstest zwischen einer dokumentierten Ratenbegrenzungsantwort und einem dauerhaften Berechtigungsfehler. GitHubs Ratenlimit-Dokumentation erklärt, dass es eine Ratenbegrenzung mit 403 oder 429 melden kann, also klassifizieren Sie nicht jeden 403 als dauerhaft nicht wiederholbar, ohne den Fehlerkontext und die dokumentierten Header zu lesen. Wenden Sie die begrenzten Warte- und Wiederholungsregeln des tatsächlichen Anbieters an. Hier wurde keine virtuelle Uhr, kein Neustarttest, kein Herstelleranruf oder keine Live-Zugriffskontrollprüfung durchgeführt.
Entscheiden Sie, was akzeptabel ist
Erstellen Sie ein Bewertungsprotokoll, in dem jedes erforderliche Verhalten, die erhaltenen Beweise und die verbleibende Unsicherheit aufgeführt sind. Behandeln Sie fehlende Mandantenisolation oder nicht behebbaren Datenverlust als Stoppbedingungen. Das Fehlen von Produktionsnachweisen muss nicht unbedingt ein Hindernis für die dokumentarische Auswertung sein, es verhindert jedoch die Behauptung, dass Live-Zugangskontrollen getestet wurden.
Vereinbaren Sie den nächsten Schritt mit dem Dienstbesitzer: Besorgen Sie sich eine Sandbox, implementieren Sie einen geschützten Adapter oder beschränken Sie den Workflow auf unterstützte Exporte. Bewahren Sie den fixierten Vertrag und die Testtermine auf, damit ein Anbieterwechsel später beurteilt werden kann. Beschränken Sie produktspezifische Ansprüche auf die dokumentierte und beobachtete Leistungsfähigkeit. In diesem Leitfaden wird keine EmailAuth API-Integration überprüft.