API-arvioinnin tulee vastata siihen, voiko asiakas noutaa luotettavasti aiotut todisteet, ei siihen, palauttaako esimerkkipyyntö HTTP 200:n. Määritä ensin työnkulku: esimerkiksi vie yhden asiakkaan vastaanottamat tiedot koontiraportit yksityiseen todistevarastoon menettämättä sivuja tai sekoittamatta vuokralaisia. Vältä olettamista, että mikä tahansa nimetty tuote tarjoaa tämän käyttöliittymän, kunnes sen nykyinen sopimus on vahvistettu.
Kiinnitä sopimus ja rajat
Tallenna palveluntarjoaja, päätepiste, API-versio, todennusmenetelmä, vuokraajan raja, kentät, sivutussäännöt ja dokumentoidut rajat. Erottele raportin identiteetti sen saapumisajasta ja ajanjaksosta, jota se kattaa. Määritä, palauttaako API raakaraportteja, normalisoituja rivejä vai johdettuja havaintoja. Nämä ovat erilaisia todisteiden populaatioita ja tarvitsevat erilaisia sovitussääntöjä.
GitHubin API-version dokumentaatio kuvaa eksplisiittisen version valinnan X-GitHub-Api-Versionilla. Tämä on konkreettinen esimerkki versiointikäytännöstä, ei todiste siitä, että GitHub vie vientiä DMARC raportteja. Varsinaista arviointia varten kirjaa nämä tiedot tarkistettavaan sopimusmuistioon ennen testausta. Tämä opas ei sisällä toimittajasopimusta, päätepistettä tai tuoteominaisuuksia.
Testaa alkuperä ja kentät
Säilytä normalisoidulle riville toimittaja, raportin tunnus, alkuperäinen ajanjakso, kuittiaika ja lähteen sormenjälki, jos saatavilla. Säilytä alkuperäinen artefakti hyväksyttyjen säilytyskontrollien alla. RFC 9990 on aggregaattiraporttien rakenteen ensisijainen viite. Kätevä JSON-skeema ei voi muuttaa raportoituja lukuja todisteiksi toimitetuista viesteistä tai palauttaa tietoja, joita vastaanottaja ei ole koskaan toimittanut.
Kysy, miten palvelu edustaa osittaista käsittelyä, virheellisiä raportteja, korjattuja tietoja ja puuttuvia keräysjaksoja. Hiljaisesti ohitettu sivu voi tehdä uskottavasta mittarista virheellisen. Pyydä näyte, joka sisältää tunnetut virheet, ja vertaa sitä itsenäisesti laskettuun syötteeseen, ei vain toiseen näyttöön, joka toimii samalla viennillä.
Harjoituksen epäonnistumisreittejä tietoisesti
Testaa monisivuinen tulos, tyhjä tulos, kaksoissyöte, kaksi tietuetta, jotka jakavat aikaleiman, peruutettu valtuustieto, vuokralaisten välinen pyyntö ja ohimenevä virhe. Seuraa dokumentoituja jatkolinkkejä tai kohdistimia. Nopeuden rajoittaminen, tietueen tila, asiaankuuluvat otsikot ja uudelleenyrityskäytäntö. GitHubin parhaat käytännöt suosittelemme nopeusrajoitussignaalien kunnioittamista ja hallitsemattoman samanaikaisuuden välttämistä; tarkat rajat kuuluvat edelleen varsinaiseen palvelusopimukseen.
Oletetaan, että sivu yksi on tallennettu, mutta sivu kaksi epäonnistuu. HTTP 200 ensimmäiselle pyynnölle ei voi perustella täydellistä vientiä. säilyttää osittaisen tilan ja käyttää palveluntarjoajan tukemaa jatko- tai uudelleenkäynnistysprosessia. Erikseen toisen valtuutetun testivuokralaisen onnistuneesti todennettu pyyntö on silti hylättävä, jos soittajalta puuttuu lupa. Nämä hypoteettiset tapaukset testaavat erilaisia vaatimuksia: täydellisyyttä ja valtuutusta.
Kun yrität uudelleen, erota dokumentoitu nopeusrajoitusvaste pysyvästä lupavirheestä. GitHubin nopeusrajoitusdokumentaatio selittää, että se voi raportoida nopeusrajoituksen 403:lla tai 429:llä, joten älä luokittele jokaista 403:a pysyvästi uudelleen yritettäväksi lukematta sen virhekontekstia ja dokumentoituja otsikoita. Käytä todellisen palveluntarjoajan rajoitettuja odotus- ja uudelleenyrityssääntöjä. Täällä ei suoritettu virtuaalista kelloa, uudelleenkäynnistystestiä, toimittajapuhelua tai reaaliaikaista kulunvalvontatarkistusta.
Päätä mikä on hyväksyttävää
Luo arviointitietue, jossa luetellaan jokainen vaadittu käyttäytyminen, saadut todisteet ja jäljellä oleva epävarmuus. Käsittele puuttuvan vuokralaisen eristämistä tai peruuttamatonta tietojen menetystä pysäytysehtoina. Tuotannon valtuustietojen puuttumisen ei tarvitse estää asiakirjojen arviointia, mutta se estää väittämästä, että reaaliaikaisia käyttöoikeuksien valvontaa on testattu.
Sovi seuraava vaihe palvelun omistajan kanssa: hanki hiekkalaatikko, ota käyttöön suojattu sovitin tai rajaa työnkulku tuettuun vientiin. Säilytä kiinnitetty sopimus ja testikalusteet, jotta palveluntarjoajan muutos voidaan arvioida myöhemmin. Pidä tuotekohtaiset väitteet rajoitettuna dokumentoituun ja havaittuun kykyyn; tässä oppaassa ei ole vahvistettu EmailAuth API -integraatiota.