Topik wawancara representatif

Wawancara Backend: Kapan API Harus Mengembalikan 409 Conflict Dibandingkan 422 Unprocessable Content?

BackendSedang
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Kapan API harus mengembalikan 409 Conflict daripada 422 Unprocessable Content? Berikan contoh untuk pembaruan konkuren, sumber daya duplikat, dan validasi field.

1. Perintah dan skenario

Sebuah API pesanan menerima permintaan JSON. Klien dapat mengirimkan data yang valid secara sintaksis dengan hubungan field yang tidak valid, memperbarui pesanan dari versi lama, atau mencoba membuat nama pengguna yang sudah ada. Tentukan batas antara 409 dan 422 agar klien tahu apakah harus mengedit permintaan, membaca ulang sumber daya, atau berhenti mencoba lagi.

2. Apa yang sedang diuji oleh pewawancara

  • Apakah Anda memisahkan semantik permintaan yang tidak dapat diproses dari konflik dengan status sumber daya saat ini.
  • Apakah Anda mengetahui bahwa mengulangi permintaan 422 yang tidak diubah biasanya menghasilkan hasil yang sama.
  • Apakah Anda menghubungkan kontrol konkurensi, percobaan ulang idempoten, dan kontrak kesalahan.
  • Apakah Anda dapat memposisikan respons 400 dan 412 yang berdekatan serta menjaga kebijakan tetap konsisten.

3. Pertanyaan klarifikasi yang perlu diajukan

  1. Apakah API menggunakan ETag, nomor versi, atau mekanisme konkurensi optimis lainnya?
  2. Apakah "nama sudah ada" dimodelkan sebagai aturan field atau sebagai status koleksi saat ini?
  3. Bisakah klien membaca ulang sumber daya dan menampilkan perbedaan (diff) kepada pengguna?
  4. Apakah tim sudah menstandarkan kode kesalahan, jalur field (field path), dan perilaku percobaan ulang?

4. Kerangka jawaban 30 detik

Klasifikasikan penyebabnya terlebih dahulu. Kembalikan 422 ketika server memahami tipe media dan sintaksis tetapi tidak dapat memproses semantik permintaan. Kembalikan 409 ketika permintaan yang dapat dipahami berkonflik dengan status sumber daya target saat ini. Gunakan 400 untuk permintaan yang tidak dapat di-parse dan 412 untuk prakondisi permintaan bersyarat yang gagal jika itu merupakan kontrak yang tepat. Akhiri dengan kode yang dapat dibaca mesin, panduan perbaikan, dan informasi versi.

5. Solusi langkah demi langkah

Langkah satu: Tentukan batas 422

422 berarti tipe konten dan sintaksis dipahami, tetapi instruksi di dalamnya tidak dapat diproses. Contohnya termasuk tanggal akhir sebelum tanggal mulai, nilai enum yang tidak diizinkan, atau kombinasi field yang tidak valid. Kegagalan ini biasanya tidak bergantung pada siapa yang terakhir mengubah sumber daya, sehingga klien harus memodifikasi payload sebelum mengirimkannya kembali.

Langkah dua: Tentukan batas 409

409 berarti permintaan berkonflik dengan status sumber daya target saat ini. Kasus umum meliputi versi usang, pembatalan pesanan yang telah dikirim, atau pembuatan sumber daya yang bertabrakan dengan sumber daya unik yang sudah ada. Sertakan versi saat ini, jenis konflik, dan langkah praktis berikutnya jika aman untuk melakukannya.

Langkah tiga: Posisikan kode-kode yang berdekatan

Gunakan 400 untuk JSON yang rusak atau sintaksis yang hilang yang diperlukan untuk mem-parse permintaan. Permintaan dengan If-Match yang gagal memenuhi kondisi yang dinyatakan dapat menggunakan 412; ini lebih tepat daripada menyebut setiap kegagalan bersyarat sebagai 409. Dokumentasikan kebijakan yang dipilih agar endpoint tidak menciptakan arti yang tidak kompatibel.

Langkah empat: Rancang percobaan ulang dan isi kesalahan (error body)

Jangan mencoba ulang secara otomatis payload 422 yang tidak diubah karena diperkirakan akan gagal lagi. Respons 409 mungkin dapat diperbaiki: baca ulang, gabungkan (merge), dan coba lagi jika jenis konflik memungkinkan, tetapi jangan pernah melakukan loop tanpa henti. Kembalikan code yang stabil, jalur field atau pengidentifikasi sumber daya, versi saat ini, dan panduan perbaikan; jauhkan kredensial dan rahasia lainnya dari respons dan log.

6. Contoh jawaban model

Saya mengklasifikasikan kegagalan sebagai masalah semantik payload atau kondisi race condition pada status sumber daya. Rentang tanggal yang terbalik, enum yang tidak valid, dan kombinasi field yang mustahil adalah 422. Server yang memahami permintaan tetapi melihat pesanan yang telah dikirim, versi yang usang, atau sumber daya unik yang sudah ada dapat mengembalikan 409. JSON yang salah format adalah 400, dan kondisi If-Match yang tidak terpenuhi bisa berupa 412.

>

Untuk 422, saya mengembalikan kode bisnis dan jalur field yang stabil agar klien dapat mengedit data. Untuk 409, saya mengembalikan jenis konflik dan versi atau status server sehingga klien dapat membaca ulang dan memilih untuk menggabungkan, membatalkan, atau mencoba lagi. Tidak ada status yang boleh memicu percobaan ulang tanpa syarat; kunci idempoten mencegah eksekusi duplikat tetapi tidak menghilangkan konflik konkurensi. Saya mendokumentasikan satu kebijakan untuk semua endpoint dan memantau bagaimana setiap kesalahan diperbaiki.

7. Kesalahan umum

  • Mengembalikan 409 untuk setiap kegagalan validasi bisnis, yang menyiratkan bahwa membaca ulang sumber daya akan memperbaikinya.
  • Mengembalikan 422 untuk konflik versi dan menyembunyikan sinyal bahwa status telah berubah.
  • Menambahkan percobaan ulang otomatis tanpa batas untuk salah satu status dan memicu lonjakan permintaan (request storm).
  • Hanya mengembalikan pesan untuk manusia tanpa kode yang stabil, jalur field, atau arahan perbaikan.
  • Memilih satu kode untuk setiap "duplikat" tanpa menentukan apakah itu aturan payload atau konflik status sumber daya.

8. Pertanyaan lanjutan dan jawaban

Pertanyaan lanjutan satu: Apakah nama pengguna duplikat harus 409 atau 422?

Jika keunikan dimodelkan sebagai status koleksi saat ini, 409 mengomunikasikan konflik status. Jika tim memodelkannya sebagai validasi semantik field, 422 dapat konsisten. Kontrak yang stabil dan perilaku klien yang dapat diprediksi lebih penting daripada label universal.

Pertanyaan lanjutan dua: Apakah setiap 409 dapat dicoba lagi?

Tidak. Konflik versi dapat dicoba lagi setelah penggabungan, sedangkan pembatalan pesanan yang telah dikirim harus berhenti dan menampilkan status saat ini. Respons harus mengomunikasikan apakah konflik tersebut dapat diperbaiki.

Pertanyaan lanjutan tiga: Bisakah 422 mewakili kegagalan izin?

Status ini tidak boleh menggantikan semantik autentikasi dan otorisasi. Autentikasi yang hilang umumnya 401, dan pemanggil terautentikasi tanpa izin umumnya 403. Cadangkan 422 untuk konten yang semantiknya tidak dapat diproses.

Sumber publik

Pertanyaan terkait