Kapan HTTP 424 Failed Dependency harus digunakan, dan bagaimana Anda merancang kontrak API yang aman untuk percobaan ulang (retry-safe)?

Skenario

Sebuah batch API memvalidasi pesanan, mereservasi inventaris, dan membuat pesanan. Jika reservasi inventaris gagal, pembuatan pesanan tidak akan pernah dijalankan. Pewawancara meminta Anda untuk merancang respons kesalahan dan memberikan justifikasi apakah HTTP 424 tepat digunakan.

Hal yang diuji

• Membedakan semantik HTTP standar dari konvensi khusus tim.
• Merepresentasikan penyelesaian parsial, pekerjaan yang dilewati, dan hasil yang tidak diketahui dalam grafik dependensi.
• Merancang idempotensi, kondisi percobaan ulang (retry), dan detail kesalahan sebagai satu kontrak utuh.

Jawaban model

Batasan 424

424 (Failed Dependency) didefinisikan oleh WebDAV RFC 4918: metode tidak dapat diselesaikan karena operasi lain gagal. Ini bukan alias umum untuk setiap kesalahan layanan hilir (downstream service). API non-WebDAV boleh mengadopsi 424, tetapi kontrak publiknya harus mendefinisikan makna, perilaku klien, dan ekspektasi kompatibilitas.

Memilih kode status

• 412 Precondition Failed: prasyarat permintaan seperti If-Match tidak terpenuhi.
• 409 Conflict: permintaan mengalami konflik dengan status sumber daya saat ini, seperti perubahan versi inventaris.
• 424 Failed Dependency: langkah ini secara eksplisit bergantung pada langkah yang gagal dalam permintaan atau alur kerja yang sama sehingga tidak dieksekusi.
• 5xx: server tidak dapat menyelesaikan permintaan karena kegagalan layanan, bukan karena hubungan permintaan menjelaskan langkah yang terblokir.

Jangan memetakan kode 500 dari sebuah dependensi secara mekanis ke 424. Pertama-tama, tentukan apakah suatu langkah dalam alur kerja ini terblokir dan apakah klien dapat mengambil tindakan berbeda berdasarkan fakta tersebut.

Isi respons dan state machine

Gunakan Problem Details RFC 9457 dengan type, title, status, dan detail yang stabil, ditambah ekstensi seperti blockedBy, operationId, retryable, dan completedSteps. Ekstensi bisnis merupakan bagian dari kontrak dan memerlukan versioning.

{
  "type": "https://api.example.com/problems/failed-dependency",
  "title": "Order creation was blocked",
  "status": 424,
  "detail": "Inventory reservation failed",
  "blockedBy": "reserve-inventory",
  "operationId": "op_123",
  "retryable": true,
  "completedSteps": ["validate-order"]
}

Percobaan ulang dan hasil yang tidak diketahui

Lakukan percobaan ulang otomatis hanya jika retryable=true dan kunci idempotensi yang sama digunakan. Jika koneksi terputus setelah reservasi inventaris di-commit, klien tidak dapat menyebut timeout tersebut sebagai 424 karena hasil di server tidak diketahui; klien harus melakukan kueri melalui operationId. Efek samping yang telah selesai tidak dapat dibatalkan hanya dengan berpura-pura bahwa permintaan kedua adalah permintaan baru; sediakan kompensasi jika bisnis memerlukannya.

Kesalahan umum

• Memperlakukan 424 sebagai status universal untuk semua kesalahan microservice.
• Hanya mengembalikan teks biasa tanpa tipe kesalahan yang stabil atau ID operasi.
• Mengulang setiap respons 424 sehingga menciptakan duplikasi reservasi atau pesanan.
• Menyembunyikan pemadaman sistem (outage) di balik 424 sehingga pemantauan tidak dapat memisahkan pemblokiran alur kerja dari kegagalan platform.

Pertanyaan lanjutan

Bisakah permintaan batch berhasil secara parsial?

Ya, tetapi kembalikan status per item, informasi idempotensi, dan detail dependensi. Status HTTP batch mendeskripsikan hasil agregat; ini tidak dapat menggantikan hasil per item. Jika bisnis memerlukan atomisitas, nyatakan apakah semua perubahan di-rollback atau tidak ada yang di-commit.

Kapan 409 lebih baik daripada 424?

Konflik versi sumber daya dan status inventaris adalah masalah sumber daya saat ini dan biasanya lebih cocok dengan 409. Gunakan 424 jika langkah saat ini dilewati karena langkah lain dalam alur kerja yang sama gagal.

Bagaimana jika dependensi mengembalikan 503?

Jika langkah saat ini terblokir dan kontrak memperlakukannya sebagai kegagalan dependensi alur kerja, 424 dapat memuat akar penyebab (root cause) di dalam detailnya. Jika layanan secara keseluruhan tidak tersedia, kembalikan 503 dan gunakan sinyal tingkat layanan seperti Retry-After. Pemantauan dan kebijakan klien harus membedakan kedua kasus tersebut.

Bagaimana cara menguji kontrak tersebut?

Cakup keberhasilan dependensi, penolakan, timeout, kehilangan koneksi setelah commit, kunci idempotensi duplikat, penyelesaian parsial, dan kueri pemulihan. Lakukan pengujian pada status, kolom Problem Details, status akhir (terminal state), dan jumlah efek samping, alih-alih hanya memeriksa angka kode HTTP.

Rubrik penilaian

Lulus

Menjelaskan asal-usul WebDAV dari 424 secara akurat, menarik batasan untuk 409, 412, dan 5xx, serta mengusulkan kunci idempotensi ditambah kueri hasil yang tidak diketahui.

Kuat

Merancang ekstensi Problem Details, status penyelesaian parsial, kategori pemantauan, dan kondisi percobaan ulang otomatis yang aman.

Luar Biasa

Memberikan justifikasi untuk setiap pilihan menggunakan atomisitas bisnis, grafik dependensi, kompensasi, dan kontrak berversi, sambil menyebutkan risiko kompatibilitas ketika 424 digunakan di luar WebDAV.

Strategi menjawab

Pertama, tetapkan asal standar kode status, lalu tentukan batasan status langkah dan efek samping; akhirnya buat keputusan menjadi konkret dengan kontrak kesalahan yang dapat dikueri dan aman untuk percobaan ulang.

Sumber

Standar kode status

• RFC 4918: WebDAV (IETF)

Semantik HTTP

• RFC 9110: HTTP Semantics (IETF)

Format kesalahan

• RFC 9457: Problem Details for HTTP APIs (IETF)