Evaluasi API harus menjawab apakah pelanggan dapat mengambil bukti yang diinginkan dengan andal, bukan apakah permintaan sampel mengembalikan HTTP 200. Tentukan alur kerja terlebih dahulu: misalnya, ekspor yang diterima satu pelanggan laporan agregat ke dalam toko bukti pribadi tanpa kehilangan halaman atau mencampurkan penyewa. Hindari berasumsi bahwa produk apa pun yang disebutkan menawarkan antarmuka ini hingga kontraknya saat ini diverifikasi.
Sematkan kontrak dan batasannya
Catat penyedia, titik akhir, versi API, metode autentikasi, batas penyewa, bidang, aturan penomoran halaman, dan batas yang didokumentasikan. Pisahkan identitas laporan dari waktu tiba dan periode yang dicakupnya. Tentukan apakah API mengembalikan laporan mentah, baris yang dinormalisasi, atau temuan turunan. Ini adalah populasi bukti yang berbeda dan memerlukan aturan rekonsiliasi yang berbeda.
Dokumentasi versi API GitHub mengilustrasikan pemilihan versi eksplisit dengan X-GitHub-Api-Version. Itu adalah contoh nyata dari praktik pembuatan versi, bukan bukti bahwa GitHub mengekspor DMARC laporan. Untuk evaluasi sebenarnya, catat rincian tersebut dalam catatan kontrak yang dapat ditinjau sebelum pengujian. Panduan ini tidak memberikan kontrak vendor, titik akhir, atau kemampuan produk.
Uji asal serta ladang
Untuk baris yang dinormalisasi, simpan pelapor, ID laporan, periode asli, waktu penerimaan, dan sidik jari sumber bila tersedia. Pertahankan artefak asli di bawah kendali retensi yang disetujui. RFC 9990 adalah referensi utama untuk struktur laporan agregat. Skema JSON yang mudah digunakan tidak dapat mengubah jumlah yang dilaporkan menjadi bukti pesan terkirim atau memulihkan informasi yang tidak pernah diberikan oleh penerima.
Tanyakan bagaimana layanan tersebut mewakili penyerapan sebagian, format laporan yang salah, data yang dikoreksi, dan periode pengumpulan yang hilang. Halaman yang dilewati secara diam-diam dapat membuat metrik yang masuk akal menjadi salah. Minta sampel yang menyertakan kesalahan yang diketahui dan bandingkan dengan masukan yang dihitung secara independen, bukan sekadar layar lain yang didukung oleh ekspor yang sama.
Latih jalur kegagalan dengan sengaja
Uji hasil multi-halaman, hasil kosong, masukan duplikat, dua catatan berbagi stempel waktu, kredensial yang dicabut, permintaan lintas penyewa, dan kesalahan sementara. Ikuti tautan atau kursor kelanjutan yang terdokumentasi. Untuk pembatasan kecepatan, status rekaman, header yang relevan, dan kebijakan percobaan ulang. Praktik terbaik GitHub merekomendasikan untuk menghormati sinyal batas tarif dan menghindari konkurensi yang tidak terkendali; batas pastinya masih termasuk dalam kontrak layanan sebenarnya.
Misalkan halaman satu disimpan tetapi halaman dua gagal. HTTP 200 untuk permintaan pertama tidak dapat membenarkan ekspor lengkap; pertahankan status parsial dan gunakan proses kelanjutan atau mulai ulang yang didukung penyedia. Secara terpisah, permintaan yang berhasil diautentikasi untuk penyewa pengujian resmi lainnya masih harus ditolak ketika penelepon tidak memiliki izin tersebut. Kasus-kasus hipotetis ini menguji persyaratan yang berbeda: kelengkapan dan otorisasi.
Untuk pengujian percobaan ulang, bedakan respons batas laju yang terdokumentasi dengan kegagalan izin permanen. Dokumentasi batas tarif GitHub menjelaskan bahwa ia dapat melaporkan pembatasan kecepatan dengan 403 atau 429, jadi jangan mengklasifikasikan setiap 403 sebagai tidak dapat dicoba ulang secara permanen tanpa membaca konteks kesalahannya dan header yang terdokumentasi. Terapkan aturan tunggu dan coba lagi yang dibatasi oleh penyedia sebenarnya. Tidak ada jam virtual, tes restart, panggilan vendor atau pemeriksaan kontrol akses langsung yang dijalankan di sini.
Putuskan apa yang dapat diterima
Buat catatan evaluasi yang mencantumkan setiap perilaku yang diperlukan, bukti yang diperoleh, dan ketidakpastian yang tersisa. Perlakukan isolasi penyewa yang hilang atau kehilangan data yang tidak dapat dipulihkan sebagai kondisi penghentian. Kurangnya kredensial produksi tidak berarti menghalangi evaluasi dokumenter, namun hal ini menghalangi klaim bahwa kontrol akses langsung telah diuji.
Setujui langkah selanjutnya dengan pemilik layanan: dapatkan sandbox, terapkan adaptor yang dilindungi, atau persempit alur kerja ke ekspor yang didukung. Simpan kontrak dan perlengkapan tes yang disematkan sehingga perubahan penyedia dapat dinilai nanti. Membatasi klaim spesifik produk pada kemampuan yang terdokumentasi dan diamati; tidak ada integrasi API EmailAuth yang diverifikasi oleh panduan ini.