409 Conflict

Penggunaan

Ketika error 409 Conflict muncul, permintaannya valid tetapi tidak dapat diselesaikan karena ketidakcocokan status. Misalnya, klien membalas sebuah posting yang sementara itu sudah dihapus, sehingga sumber daya target tidak lagi berada dalam status yang kompatibel. Server mengembalikan status ini untuk menandakan adanya konflik.

Catatan

409 Conflict berarti permintaan tersusun dengan benar tetapi berkonflik dengan status sumber daya saat ini (pembaruan bersamaan, pembuatan duplikat). 422 Unprocessable Content berarti body permintaan valid secara sintaksis tetapi tidak valid secara semantik (gagal memenuhi aturan validasi). 400 Bad Request berarti permintaannya sendiri cacat (body tidak dapat diurai, header tidak valid). 409 berkaitan dengan konflik status, 422 berkaitan dengan validasi, 400 berkaitan dengan sintaksis.

Klien diharapkan memeriksa body pesan untuk menentukan cara menyelesaikan masalah tersebut. Dalam kasus membalas posting yang telah dihapus, klien dapat memilih untuk membatalkan permintaan, memulihkan thread lama, atau membuat thread baru yang mengutip teks sebelumnya. Tindakan ini sepenuhnya menjadi tanggung jawab klien, dengan mengikuti persyaratan atau kebijakan yang ditetapkan server.

Dampak SEO

Mesin pencari seperti Google tidak mengindeks URL yang mengembalikan status 409. URL yang sebelumnya terindeks dan mengembalikan kode status ini akan dihapus dari hasil pencarian.

Contoh

Klien mencoba menandai sebuah posting blog yang ada dengan “ID = 111” menggunakan “like”. Server merespons untuk menunjukkan bahwa posting tersebut telah dibekukan dan tidak lagi menerima balasan atau tag.

Permintaan

POST /blog/update?postid=111&flag=like HTTP/1.1
Host: example.com

Respons

HTTP/1.1 409 Conflict
Content-Type: text/html
Content-Length: 288

<html>
  <head>
    <title>Blog Entry Frozen</title>
  </head>
  <body>
    <p>This post has been marked read-only. To post
    a reply or tag, change the status and try
    again.</p>
  </body>
</html>

Cara memperbaiki

409 Conflict berarti permintaan berkonflik dengan status sumber daya saat ini di server.

Ambil status sumber daya terkini sebelum mencoba lagi. Kirim permintaan GET untuk mengambil versi terbaru. Status sumber daya telah berubah sejak terakhir kali klien membaca datanya. Bandingkan ETag atau kolom versi yang dikembalikan dengan nilai yang dipegang klien.

Gunakan header kondisional untuk mendeteksi konflik. Sertakan If-Match dengan nilai ETag saat ini pada permintaan PUT dan PATCH. Server menolak permintaan ketika ETag tidak lagi cocok, sehingga mencegah penimpaan membabi buta. Pola ini disebut optimistic concurrency control.

PUT /api/resource/42 HTTP/1.1
If-Match: "abc123"
Content-Type: application/json

{"name": "updated value"}

Server merespons dengan 409 ketika klien lain memodifikasi sumber daya tersebut di antara GET dan PUT.

Gabungkan perubahan atau terapkan logika penyelesaian konflik. Bandingkan perubahan yang diinginkan klien dengan status server saat ini. Terapkan strategi penggabungan: last-write-wins, penggabungan per kolom, atau meminta pengguna akhir menyelesaikan perbedaannya. API yang memiliki kolom versi atau revisi di dalam payload mengharuskan klien menyertakan nomor versi saat ini pada permintaan pembaruan.

Selesaikan konflik sumber daya duplikat. Saat membuat sumber daya dengan POST atau PUT, server mengembalikan 409 jika sumber daya dengan pengenal unik yang sama sudah ada. Periksa entri yang sudah ada sebelum membuat yang baru dan gunakan idempotency key untuk menghindari pembuatan duplikat saat percobaan ulang.

Tangani konflik di tingkat basis data. Server aplikasi yang didukung basis data mengembalikan 409 ketika unique constraint, foreign key constraint, atau kunci (lock) tingkat baris menghalangi operasi tersebut. Body respons sering menyertakan nama constraint yang spesifik. Selesaikan konflik data yang mendasarinya (kunci duplikat, record induk yang hilang, transaksi bersamaan) sebelum mencoba lagi.

Untuk sistem kontrol versi, tarik versi terbaru dan terapkan ulang perubahannya. Ambil revisi terbaru, rekonsiliasi perbedaannya, lalu kirim ulang pembaruan tersebut. API berbasis Git (GitHub, GitLab) mengembalikan 409 ketika sebuah push berkonflik dengan perubahan upstream.

Periksa body respons untuk detail konflik. Server biasanya menyertakan informasi yang menjelaskan ketidakcocokan tersebut: kolom yang berkonflik, nilai saat ini, atau versi yang diharapkan. Gunakan data ini untuk menentukan jalur penyelesaian yang tepat.

Terapkan logika percobaan ulang dengan penyegaran status. Untuk klien otomatis, bangun loop percobaan ulang: ambil status sumber daya terkini, terapkan kembali modifikasi yang diinginkan, lalu kirim ulang. Tambahkan exponential backoff untuk menghindari membanjiri server dalam kondisi konkurensi tinggi.

Referensi kode

.NET

HttpStatusCode.Conflict

Rust

http::StatusCode::CONFLICT

Rails

:conflict

http.StatusConflict

Symfony

Response::HTTP_CONFLICT

Python3.5+

http.HTTPStatus.CONFLICT

Java

java.net.HttpURLConnection.HTTP_CONFLICT

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_CONFLICT

Angular

@angular/common/http/HttpStatusCode.Conflict