En API-evaluering skal svare på, om en kunde pålideligt kan hente det tilsigtede bevis, ikke om en prøveanmodning returnerer HTTP 200. Definer først workflowet: eksporter f.eks. én kundes modtagne samlede rapporter ind i en privat bevisbutik uden at miste sider eller blande lejere. Undgå at antage, at et navngivet produkt tilbyder denne grænseflade, indtil dets nuværende kontrakt er bekræftet.
Fastgør kontrakten og grænserne
Registrer udbyder, slutpunkt, API-version, godkendelsesmetode, lejergrænse, felter, pagineringsregler og dokumenterede grænser. Adskil en rapports identitet fra det tidspunkt, den ankom, og den periode, den dækker. Angiv, om API'en returnerer rårapporter, normaliserede rækker eller afledte resultater. Det er forskellige bevispopulationer og har brug for forskellige forsoningsregler.
GitHubs API-versionsdokumentation illustrerer eksplicit versionsvalg med X-GitHub-Api-Version. Det er et konkret eksempel på versioneringspraksis, ikke bevis for, at GitHub eksporterer DMARC rapporter. For en egentlig evaluering skal du notere disse detaljer i en kontraktnotat, der kan gennemses, før testning. Denne vejledning giver ingen leverandørkontrakt, slutpunkt eller produktkapacitet.
Test herkomst såvel som marker
For en normaliseret række skal du beholde reporter, rapport-id, original periode, modtagelsestidspunkt og kildefingeraftryk, når det er tilgængeligt. Opbevar den originale artefakt under godkendte opbevaringskontroller. RFC 9990 er den primære reference for aggregeret rapportstruktur. Et praktisk JSON-skema kan ikke omdanne rapporterede optællinger til bevis for leverede meddelelser eller gendanne oplysninger, som modtageren aldrig har leveret.
Spørg, hvordan tjenesten repræsenterer delvis indtagelse, forkert udformede rapporter, korrigerede data og manglende indsamlingsperioder. En side, der stilles springet over, kan gøre en plausibel metrik forkert. Anmod om en prøve, der inkluderer kendte fejl, og sammenlign den med uafhængigt optalt input, ikke blot en anden skærm, der drives af den samme eksport.
Træn fejlstier bevidst
Test et resultat på flere sider, et tomt resultat, duplikatinput, to poster, der deler et tidsstempel, en tilbagekaldt legitimationsoplysninger, en anmodning på tværs af lejer og en forbigående fejl. Følg dokumenterede fortsættelseslinks eller markører. Til hastighedsbegrænsning, registreringsstatus, relevante overskrifter og genforsøgspolitik. GitHubs bedste praksis anbefale at respektere hastighedsgrænsesignaler og undgå ukontrolleret samtidighed; nøjagtige grænser hører stadig til den egentlige servicekontrakt.
Antag, at side et er gemt, men side to mislykkes. En HTTP 200 for den første anmodning kan ikke retfærdiggøre en fuldstændig eksport; bevare den delvise status og bruge udbyderens understøttede fortsættelses- eller genstartsproces. Separat skal en vellykket autentificeret anmodning om en anden autoriseret testlejer stadig afvises, når den, der ringer, mangler denne bevilling. Disse hypotetiske tilfælde tester forskellige krav: fuldstændighed og autorisation.
For en genforsøgstest skal du skelne mellem et dokumenteret hastighedsgrænsesvar fra en permanent tilladelsesfejl. GitHubs hastighedsgrænsedokumentation forklarer, at den kan rapportere hastighedsbegrænsning med 403 eller 429, så du skal ikke klassificere hver 403 som permanent ikke-gentagelig uden at læse dens fejlkontekst og dokumenterede overskrifter. Anvend den faktiske udbyders afgrænsede vente- og forsøgsregler. Intet virtuelt ur, genstartstest, leverandøropkald eller direkte adgangskontrolkontrol blev udført her.
Beslut hvad der er acceptabelt
Opret en evalueringspost med en liste over hver påkrævet adfærd, de opnåede beviser og den resterende usikkerhed. Behandl manglende lejerisolering eller uopretteligt datatab som stopbetingelser. Mangel på produktionslegitimationsoplysninger behøver ikke at forhindre dokumentarisk evaluering, men det forhindrer påstand om, at live adgangskontroller blev testet.
Aftal næste trin med tjenesteejeren: Få en sandkasse, implementer en beskyttet adapter, eller indsnæv arbejdsgangen til understøttede eksporter. Behold den fastgjorte kontrakt og testarmaturer, så et udbyderskifte kan vurderes senere. Hold produktspecifikke påstande begrænset til dokumenteret og observeret kapacitet; ingen EmailAuth API-integration verificeres af denne vejledning.