Kontrak API Konsisten jadi landasan agar webhook, callback, dan sistem third-party lainnya tidak berantakan saat menerima event. Ketika separator di path, header, atau payload tidak konsisten—misalnya path tergabung dengan beberapa slash berturut-turut atau header yang berisi tanda baca yang tidak diatur—webhook bisa gagal, retry menjadi tidak idempoten, dan otentikasi token tidak pernah sampai ke penerima.
Penerapan prinsip Nontrailing separators do not spark joy menunjukkan bahwa separator ekstra yang tidak dijaga konsistensinya adalah sumber kegagalan yang berulang. Artikel ini membedah masalah tersebut, menunjukkan cara normalisasi, menjelaskan dampak terhadap token/auth, dan memberikan strategi retry serta checklist review kontrak.
Identifikasi Masalah di Webhook/Callback dengan Separator Nontrailing
Separator nontrailing mengacu pada elemen pemisah (slash, koma, titik dua) yang muncul secara tidak terduga di akhir bagian URL atau payload. Contoh nyata: klien mengirim path /orders//123 sementara penerima mengharapkan /orders/123. Otentikasi berbasis path yang masuk ke middleware bisa gagal, karena signature dihitung berdasarkan string yang berbeda.
Problem yang sama muncul ketika header seperti X-Callback-Id diakhiri dengan ; atau payload JSON menyisipkan koma ganda akibat konversi string. Webhook receiver sering kali melakukan string matching tepat, dan separator-extra membuat parsing URI, deserialisasi JSON, serta evaluasi header menjadi error.
“Nontrailing separators do not spark joy” mengingatkan kita bahwa separator tidak hanya soal estetika, melainkan kontrak: konsistensi pemisah adalah bagian dari protokol yang bisa diuji.
Debugging sering melibatkan logging request mentah dan membandingkannya dengan signature yang diharapkan. Bila separator tidak ditangani, Anda akan melihat perbedaan kecil yang menyebabkan reject signature, 400 Bad Request, atau callback yang dianggap duplikat saat seharusnya idempoten.
Normalisasi URI dan Payload untuk Kontrak API Konsisten
Normalisasi memastikan semua pihak menyepakati bentuk final dari URI, header, dan payload. Pada level URI, tampilkan aturan eksplisit: hapus separator ganda, standar trailing slash, dan encode karakter khusus. Untuk payload, pastikan order field deterministik (misalnya menggunakan library yang mendukung stable serialization) dan hindari penyisipan delimiter ekstra.
Contoh pseudocode normalisasi:
function normalizePath(rawPath) {
const segments = rawPath
.split('/')
.filter(Boolean);
return '/' + segments.join('/');
}
function normalizePayload(obj) {
return Object.keys(obj)
.sort()
.reduce((acc, key) => {
acc[key] = obj[key];
return acc;
}, {});
}
Normalisasi seperti di atas menjaga agar kontrak tetap konsisten: setiap callback memanggil URI standar dan payload tersusun dengan urutan yang sama. Ini membuat xpath signatures, token HMAC, atau schema comparison menjadi dapat diandalkan.
Selain itu, sertakan validasi kontrak sederhana sebelum mengirim webhook:
function validateContract(request) {
if (!request.path.startsWith('/events/')) {
throw new Error('Path harus awali dengan /events/');
}
if (request.path.endsWith('/') && request.path !== '/events/') {
throw new Error('Jangan sertakan trailing slash kecuali root');
}
if (request.headers['X-Custom']?.includes(';;')) {
throw new Error('Header tidak boleh mengandung separator ganda');
}
}
Dengan kombinasi normalisasi dan validasi, Anda menangkap inkonsistensi lebih awal, mencegah webhook diterima dalam format yang salah.
Dampak Auth/Token jika Separator Salah
Otentikasi webhook sering kali mengandalkan signature HMAC atau token yang dibangun dari path dan payload. Separator yang tidak konsisten mengubah input untuk signing dan menyebabkan mismatch di penerima. Misalnya, klien mengirim /orders/123/ dengan header signature yang dihitung terhadap string tersebut, tetapi server memverifikasi terhadap /orders/123. Akibatnya permintaan dianggap tidak valid, meskipun payload sama persis.
Selain itu, header yang menggunakan separator tidak konsisten (misal X-Token: abc:def vs abc:def:) memecah parsing token bearer atau custom scheme. Terapkan normalisasi header sebelum validasi token dan log perbedaan baku ketika verifikasi gagal. Catat bahwa menormalkan header tidak boleh merusak struktur yang sengaja digunakan (misalnya token base64 atau JSON Web Token).
Debugger tip: tangkap raw HTTP request, bandingkan string path + payload yang digunakan untuk signature di sisi pengirim dan penerima. Perbedaan sekecil apa pun menunjukkan soal separator.
Strategi Retry Idempoten
Retry hanya bisa aman jika payload dan path identik setiap kali. Separator nontrailing yang hilang atau berubah di retry pertama akan membuat daftar duplikat keliru. Berikut strategi untuk menjaga idempoten:
- Gunakan ID event tetap: Sertakan UUID atau timestamp unik dalam header (misal
X-Event-Id) dan pastikan tidak berubah walaupun separator disesuaikan. - Normalisasi sebelum enqueue: Masukkan data callback ke antrian setelah normalisasi agar retry menarik payload konsisten.
- Verifikasi checksum: Misalnya, sertakan checksum path+payload di database penerima sehingga setiap retry bisa dibandingkan. Pemisah yang berbeda akan mengubah checksum dan memicu alert.
- Buat middleware idempoten: Ketika menerima webhook, blokir duplikat berdasarkan
X-Event-Idplus signature. Pastikan signature menggunakan versi normalisasi, bukan string mentah yang berantakan.
Strategi ini menghindari kasus di mana retry dianggap request baru karena perbedaan sekecil separator.
Checklist Review Kontrak API
Gunakan checklist berikut sebelum merilis webhook atau callback:
- Apakah path selalu dinormalisasi (hapus double slash, trailing slash konsisten)?
- Apakah payload diserialisasi secara deterministik?
- Apakah header dijaga bebas dari separator ganda atau trailing yang tidak diinginkan?
- Apakah token/otentikasi menggunakan data yang sama seperti yang diterima penerima?
- Apakah ada pengujian retry dengan mekanisme idempoten?
- Apakah perbedaan separator dicatat di log untuk debugging signature?
Checklist ini membantu memastikan bot webhook tidak tergelincir karena detail separator yang tampak kecil namun berdampak besar.
Komentar
0 komentar
Masuk ke akun kamu untuk ikut berkomentar.
Belum ada komentar
Jadilah yang pertama ikut berdiskusi!