Ocena API powinna odpowiedzieć na pytanie, czy klient może wiarygodnie odzyskać zamierzone dowody, a nie na to, czy przykładowe żądanie zwraca HTTP 200. Najpierw zdefiniuj przepływ pracy: na przykład wyeksportuj otrzymane dowody od jednego klienta raporty zbiorcze do prywatnego magazynu dowodów bez utraty stron i mieszania najemców. Unikaj zakładania, że jakikolwiek wymieniony produkt oferuje ten interfejs, dopóki nie zostanie zweryfikowana jego bieżąca umowa.
Przypnij umowę i granice
Zapisz dostawcę, punkt końcowy, wersję API, metodę uwierzytelniania, granicę dzierżawcy, pola, reguły paginacji i udokumentowane limity. Oddziel tożsamość raportu od chwili jego otrzymania i okresu, którego dotyczy. Określ, czy interfejs API zwraca surowe raporty, znormalizowane wiersze, czy wyniki pochodne. Są to różne populacje dowodów i wymagają różnych zasad uzgadniania.
Dokumentacja wersji API GitHuba ilustruje jawny wybór wersji za pomocą X-GitHub-Api-Version. To konkretny przykład praktyki wersjonowania, a nie dowód, że GitHub eksportuje DMARC raporty. Aby dokonać faktycznej oceny, przed testowaniem zapisz te szczegóły w możliwej do sprawdzenia notatce do umowy. Ten przewodnik nie zawiera umowy z dostawcą, punktu końcowego ani możliwości produktu.
Sprawdź pochodzenie i pola
W przypadku znormalizowanego wiersza zachowaj osobę zgłaszającą, identyfikator raportu, pierwotny okres, godzinę otrzymania i odcisk palca źródła, jeśli jest dostępny. Zachowaj oryginalny artefakt pod zatwierdzonymi środkami kontroli przechowywania. RFC 9990 jest głównym punktem odniesienia dla struktury raportu zbiorczego. Wygodny schemat JSON nie może przekształcić zgłoszonych liczników w dowód dostarczenia wiadomości ani odzyskać informacji, których odbiorca nigdy nie dostarczył.
Zapytaj, w jaki sposób usługa reprezentuje częściowe przetworzenie, zniekształcone raporty, poprawione dane i brakujące okresy gromadzenia danych. Cicho pominięta strona może spowodować, że wiarygodne dane będą błędne. Poproś o próbkę zawierającą znane błędy i porównaj ją z niezależnie zliczonymi danymi wejściowymi, a nie tylko z innym ekranem zasilanym przez ten sam eksport.
Celowo ćwicz ścieżki niepowodzeń
Przetestuj wynik wielostronicowy, pusty wynik, zduplikowane dane wejściowe, dwa rekordy dzielące sygnaturę czasową, odwołane poświadczenie, żądanie między dzierżawcami i przejściowy błąd. Postępuj zgodnie z udokumentowanymi linkami kontynuacyjnymi lub kursorami. Do ograniczania szybkości, statusu rekordu, odpowiednich nagłówków i zasad ponawiania. Najlepsze praktyki GitHuba zalecają przestrzeganie sygnałów ograniczających przepływność i unikanie niekontrolowanej współbieżności; Dokładne limity nadal należą do faktycznej umowy o świadczenie usług.
Załóżmy, że pierwsza strona jest zapisana, ale strona druga nie działa. HTTP 200 dla pierwszego żądania nie może uzasadniać pełnego eksportu; zachowaj status częściowy i skorzystaj z obsługiwanego przez dostawcę procesu kontynuacji lub ponownego uruchomienia. Oddzielnie pomyślnie uwierzytelnione żądanie innego autoryzowanego dzierżawcy testowego musi zostać odrzucone, jeśli obiekt wywołujący nie ma tego uprawnienia. Te hipotetyczne przypadki testują różne wymagania: kompletność i autoryzację.
W przypadku testu ponawiania należy rozróżnić udokumentowaną odpowiedź dotyczącą ograniczenia szybkości od trwałego błędu uprawnień. Dokumentacja dotycząca limitów szybkości GitHuba wyjaśnia, że może zgłosić ograniczenie szybkości za pomocą 403 lub 429, więc nie klasyfikuj każdego 403 jako trwale niemożliwego do ponownej próby bez przeczytania kontekstu błędu i udokumentowanych nagłówków. Zastosuj ograniczone reguły oczekiwania i ponawiania próby rzeczywistego dostawcy. Nie wykonano tutaj żadnego zegara wirtualnego, testu ponownego uruchomienia, wezwania dostawcy ani kontroli dostępu na żywo.
Zdecyduj, co jest dopuszczalne
Utwórz zapis oceny zawierający listę każdego wymaganego zachowania, uzyskanych dowodów i pozostałej niepewności. Traktuj brakującą izolację dzierżawcy lub nieodwracalną utratę danych jako warunki zatrzymania. Brak poświadczeń produkcyjnych nie musi uniemożliwiać oceny dokumentów, ale uniemożliwia twierdzenie, że przetestowano kontrolę dostępu na żywo.
Uzgodnij z właścicielem usługi kolejny krok: uzyskaj piaskownicę, zaimplementuj chroniony adapter lub zawęź przepływ pracy do obsługiwanych eksportów. Zachowaj przypiętą umowę i elementy testowe, aby móc później ocenić zmianę dostawcy. Ogranicz oświadczenia dotyczące konkretnego produktu do udokumentowanych i zaobserwowanych możliwości; w tym przewodniku nie jest weryfikowana żadna integracja API EmailAuth .