Membangun API Idempotent: Solusi Elegan Menangani Double Request

Pendahuluan

Pernah nggak sih kamu bikin fitur untuk menambahkan data, misalnya bikin produk baru, lalu tiba-tiba datanya masuk dua kali di database? Biasanya ini terjadi karena user tidak sabar saat koneksi lambat, lalu menekan tombol submit berkali-kali. Masalah double request ini sering bikin developer pusing karena membuat laporan data menjadi kacau.

Masalah yang Ingin Diselesaikan

Skenario klasiknya seperti ini ada user ingin menambahkan produk misalnya iPhone Pro Max. Klien mengirim request POST ke backend, lalu backend memprosesnya dan memberikan ID auto-increment misalnya dengan id 1. Karena loading lama, user tidak sengaja double-click tombol simpan.

Klien mengirim request kedua dengan data yang persis sama. Backend kembali memprosesnya dan memberikan ID baru. Hasilnya? Ada dua produk iPhone Pro Max kembar di database yang seharusnya hanya ada satu.

Kenapa API Idempotent Lebih Efisien?

Menyerahkan tanggung jawab pencegahan double submit hanya pada frontend misalnya men-disable tombol itu tidak cukup aman karena frontend bisa di manipulasi. API yang kebal terhadap double request Idempotent menyelesaikan masalah langsung ke akarnya.

Keuntungan utamanya antara lain:

• Integritas data di database tetap terjamin rapi.
• User experience (UX) lebih baik karena user tidak akan melihat pesan error yang membingungkan.
• Sistem kebal terhadap celah bug dari network timeout atau ketidaksengajaan user.

Konsep Dasar

Secara sederhana, idempotent berarti: mau kamu mengirim request yang sama satu kali atau seratus kali, hasil akhir di database tetap sama. Dalam standar HTTP, method seperti GET, PUT, PATCH, dan DELETE secara natural memang sudah bersifat idempotent. Yang sering jadi biang kerok adalah POST, karena tugasnya meng-create data baru.

Sebagai analogi di dunia e-commerce, setiap barang pasti punya barcode atau SKU (Stock Keeping Unit) yang unik. Jika sistem kasir di-scan dengan barcode yang sama dua kali secara beruntun dengan cepat. Sistem yang pintar tidak akan membuat dua entri barang yang terpisah, melainkan menganggapnya sebagai barang yang sama.

Gambaran Arsitektur

Untuk membuat endpoint POST menjadi idempotent, kita tidak boleh murni mengandalkan ID auto-increment dari database. Klien harus mengirimkan satu Unique Column (misal: SKU) sebagai penanda unik. Berikut adalah gambaran arsitekturnya:

+--------+      1. POST /products (Data: iPhone 15, SKU: IP-15)   +---------+
|        | -----------------------------------------------------> |         |
| Client |                                                        | Backend |
|        | <----------------------------------------------------- |         |
+--------+      2. Insert DB & Return 200 OK                      +---------+
     |
     |          3. POST /products (Data: iPhone 15, SKU: IP-15)
     |             (User double click)
     | -----------------------------------------------------> +---------+
     |                                                        | Backend |
     | <----------------------------------------------------- | Cek SKU |
                4. SKU ada! Ubah operasi jadi UPDATE.         +---------+
                   Return 200 OK. Total record tetap 1.