Kode respons HTTP untuk POST ketika sumber daya sudah ada

842

Saya sedang membangun server yang memungkinkan klien untuk menyimpan objek. Objek-objek tersebut sepenuhnya dibangun di sisi klien, lengkap dengan ID objek yang permanen untuk seumur hidup objek.

Saya telah mendefinisikan API sehingga klien dapat membuat atau memodifikasi objek menggunakan PUT:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{Id} adalah ID objek, jadi itu adalah bagian dari URI Permintaan.

Sekarang, saya juga mempertimbangkan untuk mengizinkan klien membuat objek menggunakan POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Karena POST dimaksudkan sebagai operasi "tambahkan", saya tidak yakin apa yang harus dilakukan jika objek sudah ada di sana. Haruskah saya memperlakukan permintaan sebagai permintaan modifikasi atau haruskah saya mengembalikan beberapa kode kesalahan (yang)?

rest http http-status-codes vmj
sumber
5
Pada Juni 2016, FB secara terang-terangan menetapkan 200 pada pendaftaran saat email ada
Hijau
4
Github API mengembalikan 422 ketika mencoba membuat sumber daya (tim / repo) dengan nama yang sudah digunakan
Ken
1
Itu tergantung apakah Anda menganggap keberadaan objek itu kesalahan atau tidak. Jika Anda memproses append, 200 atau 204 adalah kode respons yang paling tepat.
Suncat2000

Jawaban:

1057

Perasaan saya 409 Conflictadalah yang paling tepat, namun, jarang terlihat di alam liar tentu saja:

Permintaan tidak dapat diselesaikan karena konflik dengan kondisi sumber daya saat ini. Kode ini hanya diperbolehkan dalam situasi di mana diharapkan pengguna dapat menyelesaikan konflik dan mengirimkan kembali permintaan. Badan respons HARUS menyertakan informasi yang cukup bagi pengguna untuk mengenali sumber konflik. Idealnya, entitas respons akan mencakup informasi yang cukup bagi pengguna atau agen pengguna untuk memperbaiki masalah; Namun, itu mungkin tidak mungkin dan tidak diperlukan.

Konflik kemungkinan besar terjadi sebagai respons terhadap permintaan PUT. Misalnya, jika versi sedang digunakan dan entitas yang PUT menyertakan perubahan pada sumber daya yang bertentangan dengan yang dibuat oleh permintaan sebelumnya (pihak ketiga), server mungkin menggunakan respons 409 untuk menunjukkan bahwa ia tidak dapat menyelesaikan permintaan . Dalam hal ini, entitas respons kemungkinan akan berisi daftar perbedaan antara dua versi dalam format yang ditentukan oleh Tipe Konten respons.

Terkutuk
sumber
11
mengapa tidak meminta 400 Permintaan Buruk? Bagi saya ini terlihat seperti kesalahan validasi (Anda memberikan payload yang salah dengan id ilegal).
manuel aldana
314
400 => "Permintaan tidak dapat dipahami oleh server karena sintaksis cacat" . Dan server mengerti dengan sempurna, tetapi tidak dapat mematuhi karena konflik. Tidak ada yang salah dengan permintaan & sintaksis, hanya masalah data. 400 akan langsung membuat saya percaya seluruh mekanisme yang saya gunakan cacat, bukan hanya data.
Wrikken
42
@ Wikrik Itu tidak lagi benar. HTTP 400 diubah dalam RFC 7231 yang berarti "server tidak dapat atau tidak akan memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien (misalnya, sintaks permintaan salah bentuk, pembingkaian pesan permintaan tidak valid, atau perutean permintaan menipu)." Saya tidak mengatakan 400 adalah penggunaan yang benar dalam kasus ini tetapi bisa benar dengan definisi baru 400.
javajavajavajavajavajava
19
@javajavajavajavajava: masih, data duplikat bukan 'kesalahan klien' dalam pikiran saya, tapi itu di mata yang melihatnya tentu saja.
Wrikken
21
Saya kembali HTTP 409dengan Locationtajuk yang menunjuk ke sumber daya yang ada / bertentangan.
Gili
100

Menurut RFC 7231 , 303 See Other MUNGKIN digunakan Jika hasil pemrosesan POST akan setara dengan representasi sumber daya yang ada .

Nullius
sumber
4
Menurut pendapat saya, ini mungkin jawaban yang diterima. Meskipun "MEI" menunjukkan item yang sepenuhnya opsional, itu adalah satu-satunya kode respons yang disarankan oleh dokumentasi RFC 7231 resmi .
Nando
16
Ini adalah jawaban yang paling tenang.
Seth
6
Saya pikir konteks itu penting. Sebagai contoh: mengembalikan 303 menyiratkan pengalihan ke sumber daya yang ditemukan diperlukan. Itu mungkin masuk akal di server ke server panggilan, tetapi jika Anda menjalankan melalui proses pendaftaran pengguna, itu tidak masuk akal sama sekali.
Sinaesthetic
11
Maaf, saya downvoting ini. HTTP 300 adalah tentang pengalihan, dan pengalihan ke objek lain yang mungkin memiliki sifat berbeda akan sangat menyesatkan.
Michael Scheper
6
Anda tidak perlu minta maaf. Namun, jika representasi itu setara dengan sumber daya yang ada, bagaimana ia bisa memiliki sifat yang berbeda? Dan bahkan jika itu akan terjadi, bagaimana pengalihan akan menyesatkan? OP mengatakan: Saya tidak yakin apa yang harus dilakukan jika objek sudah ada di sana. Ini sebenarnya adalah objek yang 'sama'. Mengapa redirect menyesatkan? Anda sedang berbicara tentang objek lain yang dalam pikiran OP jelas tidak.
Nullius
86

Secara pribadi saya pergi dengan ekstensi WebDAV 422 Unprocessable Entity.

Menurut RFC 4918

The 422 Unprocessable Entitykode status berarti server memahami jenis konten dari entitas permintaan (karenanya 415 Unsupported Media Typekode status yang tidak pantas), dan sintaks dari entitas permintaan benar (dengan demikian 400 Bad Requestkode status yang tidak pantas) tapi tidak dapat memproses instruksi yang terdapat.

Gareth
sumber
19
Ini adalah pemikiran yang menarik, dan mendorong saya untuk akhirnya membaca RFC WebDAV. Namun, saya pikir arti dari 422 adalah bahwa permintaan dan entitas yang disertakan secara sintaksis benar tetapi secara semantik tidak masuk akal.
vmj
4
JSON salah bentuk bukan entitas yang benar secara sintaksis, jadi 422saya
menganggapnya
7
Saya tidak akan pergi dengan ini. Dari URL yang sama yang dirujuk dalam jawaban: "Sebagai contoh, kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi yang benar (yaitu, secara sintaksis benar), tetapi secara XML salah, instruksi XML." Ini adalah arti sebenarnya dari entitas yang tidak dapat diproses, tidak seperti halnya ketika Anda mengirim entitas permintaan yang sepenuhnya valid dengan sintaks DAN semantik yang valid, tetapi satu-satunya masalah adalah konflik dengan entitas yang ada. Sebenarnya, jika semantik dari entitas yang diminta tidak valid, seharusnya tidak ada entitas yang sama dengan yang ada.
Tamer Shlash
1
Menambahkan ke komentar Tamer, jika permintaan kedua datang lebih dulu, maka itu akan berhasil, yang tidak akan mungkin jika itu benar secara semantik. Karenanya dalam semantik yang benar tidak berlaku di sini.
Harish
4
@ Pemain Mengapa begitu? Perintah "Tolong buat objek xy" secara sintaksis benar. Secara semantik benar hanya jika dimungkinkan untuk membuat objek xy. Jika objek xy sudah ada, itu tidak bisa lagi dibuat, maka ini adalah kesalahan semantik.
Hagen von Eitzen
48

Ini semua tentang konteks , dan juga siapa yang bertanggung jawab untuk menangani duplikat dalam permintaan (server atau klien atau keduanya)

Jika server hanya mengarahkan duplikat , lihat 4xx:

  • 400 Bad Request - ketika server tidak akan memproses permintaan karena itu jelas kesalahan klien
  • 409 Conflict - jika server tidak akan memproses permintaan, tetapi alasan untuk itu bukan kesalahan klien
  • ...

Untuk penanganan duplikat secara implisit , lihat 2XX:

  • 200 OK
  • 201 Dibuat
  • ...

jika server diharapkan mengembalikan sesuatu , lihat 3XX:

  • 302 Ditemukan
  • 303 Lihat Lainnya
  • ...

ketika server mampu menunjukkan sumber daya yang ada, itu berarti pengalihan.

Jika hal di atas tidak cukup, selalu merupakan praktik yang baik untuk menyiapkan beberapa pesan kesalahan di tubuh respons.

Sławomir Lenart
sumber
2
Permintaan tidak menggandakan sumber daya, itu menambahkan data ke satu. Menurut pendapat saya, jawaban Anda adalah yang terbaik dari semuanya.
Suncat2000
28

Mungkin terlambat bermain, tetapi saya menemukan masalah semantik ini ketika mencoba membuat REST API.

Untuk sedikit memperluas jawaban Wrikken, saya pikir Anda dapat menggunakan salah satu 409 Conflictatau 403 Forbiddenbergantung pada situasinya - singkatnya, gunakan kesalahan 403 ketika pengguna sama sekali tidak dapat menyelesaikan konflik dan menyelesaikan permintaan (mis. Mereka tidak dapat mengirim DELETEmeminta untuk menghapus sumber daya secara eksplisit), atau menggunakan 409 jika sesuatu dapat dilakukan.

10.4.4 403 Dilarang

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang. Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada publik mengapa permintaan itu belum dipenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya.

Saat ini, seseorang mengatakan "403" dan masalah izin atau otentikasi muncul di benak, tetapi spek itu mengatakan bahwa pada dasarnya server memberi tahu klien bahwa itu tidak akan melakukannya, jangan tanya lagi, dan inilah mengapa klien tidak boleh 't.

Adapun PUTvs. POST... POSTharus digunakan untuk membuat instance baru dari sumber daya ketika pengguna tidak memiliki cara untuk atau tidak seharusnya membuat pengidentifikasi untuk sumber daya. PUTdigunakan ketika identitas sumber daya diketahui.

9.6 PUT

...

Perbedaan mendasar antara permintaan POST dan PUT tercermin dalam arti berbeda dari Request-URI. URI dalam permintaan POST mengidentifikasi sumber daya yang akan menangani entitas terlampir. Sumber daya itu bisa berupa proses penerimaan data, gateway ke beberapa protokol lain, atau entitas terpisah yang menerima anotasi. Sebaliknya, URI dalam permintaan PUT mengidentifikasi entitas yang dilampirkan dengan permintaan - agen pengguna tahu apa yang dimaksud dengan URI dan server TIDAK HARUS mencoba menerapkan permintaan tersebut ke sumber daya lain. Jika server ingin agar permintaan diterapkan ke URI yang berbeda,

itu HARUS mengirim respons 301 (Dipindahkan Secara Permanen); agen pengguna MUNGKIN kemudian membuat keputusan sendiri mengenai apakah akan mengarahkan permintaan atau tidak.

p0lar_bear
sumber
7
Saya pikir 403 Forbidden menyiratkan bahwa, meskipun pengguna diautentikasi , dia tidak berwenang untuk melakukan tindakan yang diminta. Saya tidak akan menggunakannya untuk kesalahan validasi. Contoh : Tidak masuk, saya mencoba menghapus sesuatu. Server mengirimi saya 401 Tidak Resmi (yang hanya bernama buruk, seharusnya 401 Tidak Diauthentikasi ). Saya masuk dan mencoba lagi. Kali ini server memeriksa izin saya, melihat saya tidak diizinkan dan mengembalikan 403 Dilarang . Lihat juga pertanyaan ini .
Stijn de Witt
Hm ... benar. Pikiran di sini melompat tepat untuk memberi tahu pengguna bahwa otorisasi mereka membuat sumber daya tidak dapat diubah dalam kasus penggunaan OP - sudah ada, Anda tidak memiliki izin untuk melakukan apa pun untuk menyelesaikan konflik, jangan mencoba membuat sumber daya lagi.
p0lar_bear
3
Menurut spesifikasi, tersirat bahwa kesalahan 409 tidak dapat dikembalikan oleh POSTpermintaan (bila digunakan dengan benar), karena menyatakan bahwa ia harus dikembalikan ketika bertentangan dengan sumber daya target . Karena sumber daya target belum diposting, itu tidak mungkin bertentangan, dan dengan demikian untuk membalas dengan 409 Conflicttidak masuk akal.
Grant Gryczan
1
Saya tidak akan menyimpulkan bahwa kesalahan 409 tidak dapat dikembalikan oleh POST, pada kenyataannya, saya akan menyimpulkan sebaliknya karena "Konflik paling mungkin terjadi dalam menanggapi permintaan PUT." tampaknya menunjukkan bahwa metode permintaan lain juga dapat menggunakan kode ini. Selain itu, "Badan respons harus mencakup informasi yang cukup bagi pengguna untuk mengenali sumber konflik. Idealnya, entitas respons akan mencakup informasi yang cukup bagi pengguna atau agen pengguna untuk memperbaiki masalah; namun, itu mungkin tidak mungkin dan tidak wajib . " ( webdav.org/specs/rfc2616.html#status.409 )
JWAspin
14

"302 Found" terdengar logis untukku. Dan RFC 2616 mengatakan bahwa itu BISA dijawab untuk permintaan selain GET dan HEAD (dan ini pasti termasuk POST)

Tapi itu tetap membuat pengunjung pergi ke URL ini untuk mendapatkan sumber daya "Ditemukan" ini, oleh RFC. Untuk membuatnya pergi langsung ke URL "Ditemukan" yang asli, seseorang harus menggunakan "303 See Other", yang masuk akal, tetapi memaksa panggilan lain untuk MENDAPATKAN URL berikut. Sisi baiknya, GET ini bisa di-cache.

Saya pikir saya akan menggunakan "303 See Other" . Saya tidak tahu apakah saya bisa merespons dengan "benda" yang ditemukan di dalam tubuh, tetapi saya ingin melakukannya untuk menyimpan satu perjalanan pulang pergi ke server.

UPDATE: Setelah membaca ulang RFC, saya masih berpikir bahwa inexistent "4XX + 303 Ditemukan" kode harus benar. Namun, "409 Conflict" adalah kode jawaban terbaik yang ada (seperti yang ditunjukkan oleh @Wrikken), mungkin termasuk header Lokasi yang menunjuk ke sumber daya yang ada.

alanjd
sumber
88
Status 3xx dimaksudkan untuk pengalihan
Aviram Netanel
1
"Sumber daya yang diminta tinggal sementara di bawah URI yang berbeda." dari w3.org/Protocols/rfc2616/rfc2616-sec10.html
statueofmike
1
IMHO, "307 Temporary Redirect" adalah redirect sementara yang sebenarnya. "302" ambigu, tapi "DITEMUKAN !!" adalah pesan yang sangat diinginkan di sini. Kompromi terbaik yang tidak ambigu adalah "303 See Other" pada semantik HTTP. Saya akan memilih "303 See Other".
alanjds
@DavidVartanian Hum ... Saya tidak melihat kesalahan di sini. Klien mengirim permintaan yang tepat, tetapi bagaimana mengatakan "Maaf, tetapi apa yang Anda coba buat di sini sudah ada DI SANA"? Tampaknya pekerjaan untuk 3xx. Ini bukan 4xx untuk saya, karena tidak ada kesalahan klien.
alanjds
1
@DavidVartanian Terima kasih atas diskusi. Diperbarui jawabannya menuju 409 . Klien salah untuk meminta hal-hal yang tidak mungkin, bahkan jika tidak tahu bahwa itu tidak mungkin.
alanjds
11

Saya tidak berpikir Anda harus melakukan ini.

POST, seperti yang Anda tahu, memodifikasi koleksi dan digunakan untuk MENCIPTAKAN item baru. Jadi, jika Anda mengirim id (saya pikir itu bukan ide yang baik), Anda harus memodifikasi koleksi, yaitu, memodifikasi item, tetapi membingungkan.

Gunakan itu untuk menambahkan item, tanpa id. Ini praktik terbaik.

Jika Anda ingin menangkap batasan UNIK (bukan id), Anda dapat merespons 409, seperti yang dapat Anda lakukan dalam permintaan PUT. Tapi bukan ID.

Alfonso Tienda
sumber
Bagaimana dengan objek yang memiliki relasi tabel gabung? Katakanlah kita memiliki akun, produk, dan akun_produk sebagai tabel basis data. Saya ingin menambahkan produk ke akun, jadi saya ingin memposting ke / akun / {id} / produk dengan product_id. Jika hanya satu hubungan akun-produk diperbolehkan, apa yang harus saya kembalikan?
partkyle
2
Lupakan tabel database. Katakanlah suatu produk hanya dapat dikaitkan dengan suatu akun ... Maka itu adalah satu ke banyak hubungan. Jadi, POST / produk / {id} dengan {'akun': account_id}. Jika Anda memiliki kardinalitas maks ditetapkan ke '1' (hubungan satu ke satu) .... Mengapa mereka dipisahkan objek istirahat? Kesalahan kardinalitas hanya 400 err. Tetap sederhana. Saya harap saya mengerti pertanyaan Anda.
Alfonso Tienda
Saya hanya mengajukan pertanyaan ini juga dan bagi saya ID bukan ID teknis pada database tetapi sesuatu seperti kode perusahaan. Dalam aplikasi ini pengguna manajer dapat membuat perusahaan dan harus memberi mereka kode. Ini adalah ID perusahaan untuk pengguna, terlepas dari kenyataan bahwa tabel DB juga memiliki ID teknis. Jadi dalam kasus saya, saya akan mengembalikan 409 jika kode perusahaan yang sama sudah ada.
AlexCode
@partkyle Berhenti menggunakan PK sebagai ID publik !!
Sinaesthetic
Beberapa entitas memiliki batasan unik pada mereka, bukan hanya id. Seperti akun, Anda tidak dapat membuat akun jika pengguna tidak memberikan nama pengguna. Dan menambahkan akun tanpa nama pengguna jelas tidak mungkin
rocketspacer
9

Saya akan pergi dengan 422 Unprocessable Entity, yang digunakan ketika permintaan tidak valid tetapi masalah tidak dalam sintaks atau otentikasi.

Sebagai argumen terhadap jawaban lain, menggunakan 4xxkode non- kesalahan akan menyiratkan itu bukan kesalahan klien, dan jelas itu. Untuk menggunakan 4xxkode non- kesalahan untuk mewakili kesalahan klien sama sekali tidak masuk akal.

Tampaknya itu 409 Conflictadalah jawaban yang paling umum di sini, tetapi, menurut spesifikasi, itu menyiratkan bahwa sumber daya sudah ada dan data baru yang Anda lamar tidak sesuai dengan keadaan saat ini. Jika Anda mengirimPOSTmeminta, dengan, misalnya, nama pengguna yang sudah diambil, itu sebenarnya tidak bertentangan dengan sumber daya target, karena sumber daya target (sumber daya yang Anda coba buat) belum diposting. Ini adalah kesalahan khusus untuk kontrol versi, ketika ada konflik antara versi sumber daya yang disimpan dan versi sumber daya yang diminta. Ini sangat berguna untuk tujuan itu, misalnya ketika klien telah men-cache versi lama sumber daya dan mengirimkan permintaan berdasarkan versi yang salah yang tidak lagi valid secara kondisi. "Dalam hal ini, perwakilan respons kemungkinan akan berisi informasi yang berguna untuk menggabungkan perbedaan berdasarkan riwayat revisi." Permintaan untuk membuat pengguna lain dengan nama pengguna itu tidak dapat diproses, tidak ada hubungannya dengan kontrol versi.

Sebagai catatan, 422 juga merupakan kode status yang digunakan GitHub ketika Anda mencoba membuat repositori dengan nama yang sudah digunakan.

Berikan Gryczan
sumber
422 adalah spesifikasi webdav jadi saya tidak akan menyarankan untuk menggunakan ini untuk REST API
rwenz3l
7

Saya pikir untuk REST, Anda hanya perlu membuat keputusan tentang perilaku untuk sistem tertentu dalam hal ini, saya pikir jawaban "benar" akan menjadi salah satu dari beberapa jawaban yang diberikan di sini. Jika Anda ingin permintaan berhenti dan bersikap seolah-olah klien membuat kesalahan yang perlu diperbaiki sebelum melanjutkan, maka gunakan 409. Jika konflik benar-benar tidak penting dan ingin membuat permintaan tetap berjalan, maka balas dengan mengarahkan ulang klien ke entitas yang ditemukan. Saya pikir API REST yang tepat harus mengarahkan ulang (atau setidaknya memberikan header lokasi) ke titik akhir GET untuk sumber daya yang mengikuti POST, jadi perilaku ini akan memberikan pengalaman yang konsisten.

EDIT: Perlu dicatat bahwa Anda harus mempertimbangkan PUT karena Anda memberikan ID. Maka perilakunya sederhana: "Saya tidak peduli apa yang ada di sana sekarang, letakkan benda ini di sana." Artinya, jika tidak ada di sana, itu akan dibuat; jika ada sesuatu di sana itu akan diganti. Saya pikir POST lebih tepat ketika server mengelola ID itu. Memisahkan kedua konsep pada dasarnya memberi tahu Anda cara menghadapinya (yaitu PUT idempoten sehingga harus selalu berfungsi selama payload divalidasi, POST selalu menciptakan, jadi jika ada tabrakan ID, maka 409 akan menggambarkan konflik itu) .

Sinaesthetic
sumber
Menurut spesifikasi, tersirat bahwa kesalahan 409 tidak dapat dikembalikan oleh POSTpermintaan (bila digunakan dengan benar), karena menyatakan bahwa ia harus dikembalikan ketika bertentangan dengan sumber daya target . Karena sumber daya target belum diposting, itu tidak mungkin bertentangan, dan dengan demikian untuk membalas dengan 409 Conflicttidak masuk akal.
Grant Gryczan
Imo luar biasa. Jika Anda memposting ke / pengguna maka sumber daya adalah koleksi alih-alih catatan individu / pengguna / {id}
Sinaesthetic
Ini adalah kesalahan khusus untuk kontrol versi, ketika ada konflik antara versi sumber daya yang disimpan dan versi sumber daya yang diminta. Ini sangat berguna untuk tujuan itu, misalnya ketika klien telah men-cache versi lama sumber daya dan mengirimkan permintaan berdasarkan versi yang salah yang tidak lagi valid secara kondisi. "Dalam hal ini, perwakilan respons kemungkinan akan berisi informasi yang berguna untuk menggabungkan perbedaan berdasarkan riwayat revisi."
Grant Gryczan
Saya suka saran Anda untuk digunakan PUT.
Grant Gryczan
4

Pengobatan potensial lain adalah menggunakan PATCH. PATCH didefinisikan sebagai sesuatu yang mengubah keadaan internal dan tidak terbatas pada penambahan.

PATCH akan menyelesaikan masalah dengan memungkinkan Anda memperbarui item yang sudah ada. Lihat: RFC 5789: PATCH

Martin Kersten
sumber
2
Tambalan seperti PUT tetapi bukan pengganti yang lengkap. Ini digunakan untuk memodifikasi sepotong sumber daya seperti menambahkan, menghapus, atau memodifikasi satu elemen sumber daya alih-alih menggantinya secara keseluruhan.
Sinaesthetic
4

Mengapa tidak diterima ? Ini permintaan OK (200-an), tidak ada kesalahan klien (400-an), per se.

Dari 10 Definisi Kode Status :

"202 Diterima. Permintaan telah diterima untuk diproses, tetapi pemrosesan belum selesai."

... karena itu tidak perlu diselesaikan, karena sudah ada. Klien tidak tahu itu sudah ada, mereka tidak melakukan kesalahan.

Saya bersandar untuk melempar 202, dan mengembalikan konten serupa ke apa yang /{resource}/{id}akan didapat GET .

Phillip Harrington
sumber
21
Jawaban ini salah. 202 berarti server tidak menemukan masalah dengan permintaan, tetapi memilih untuk memproses permintaan setelah merespons. Ini juga berarti bahwa mengharapkan pemrosesan menjadi sukses. Dalam kasus kami, server tahu bahwa pemrosesan akan gagal, jadi 202 adalah respons yang salah.
Adrian
4
Contoh dari 202 akan menjadi antrian atau berlangganan. Dengan kata lain, hasil dari permintaan mungkin tidak tersedia segera jika Anda menanyakannya saat ini.
Sinaesthetic
1
Ini akan sesuai jika server masih memproses permintaan. 200 atau 204 akan lebih umum. Karena OP membuat permintaan tambahan, keberadaan objek adalah kondisi yang diharapkan dan bukan kesalahan.
Suncat2000
Tidak ada gunanya mengatakan kepada klien bahwa permintaan itu diterima karena Anda sudah tahu itu bukan!
lucastamoios
1
@Adrian dan lucastamoios saya pikir Anda berdua mengasumsikan server membaca secara sinkron dari database, sebelum memberikan respons. Ini tidak selalu terjadi, jadi jawaban ini tidak "salah", karena server tidak selalu "tahu" tentang catatan yang ada. Ini sangat banyak terjadi dalam sistem asinkron di mana lapisan api hanya mencatat permintaan untuk diproses oleh pekerja latar belakang.
gsaslis
2

Stumbled atas pertanyaan ini sambil memeriksa kode yang benar untuk catatan duplikat.

Maafkan ketidaktahuan saya tapi saya tidak mengerti mengapa semua orang mengabaikan kode "300" yang dengan jelas mengatakan "pilihan ganda" atau "ambigu"

Menurut pendapat saya ini akan menjadi kode sempurna untuk membangun sistem non standar atau tertentu untuk Anda gunakan sendiri. Saya bisa salah juga!

https://tools.ietf.org/html/rfc7231#section-6.4.1

Hitin
sumber
Pemahaman saya: "kode status menunjukkan bahwa sumber daya target memiliki lebih dari satu representasi ... informasi tentang alternatif disediakan sehingga pengguna (atau agen pengguna) dapat memilih representasi yang disukai dengan mengarahkan permintaannya ke satu atau lebih dari itu pengidentifikasi "Kami secara eksplisit berusaha mencegah lebih dari satu representasi. Tidak ada opsi. Tidak ada alternatif bagi klien untuk dipilih. Klien harus mengirim ulang dengan id yang berbeda. Dengan itu, orang juga harus mempertimbangkan apakah id unik harus dihasilkan di klien vs server.
musicin3d
Semantik, klien mengatakan "Buat ini" dan server merespons dengan mengatakan "Buka di sini sebagai gantinya". Pembicaraan itu tidak masuk akal. Hampir seolah-olah server memberi tahu klien untuk "mengirim ke lokasi ini sebagai gantinya". 300-an lebih merupakan respons yang lebih tepat untuk permintaan GET atau POST dalam kasus di mana server merespons dengan "Oke, saya buat dan ada di sini" ..
Sinaesthetic
2

Lebih mungkin 400 Bad Request

6.5.1. 400 permintaan Buruk


Kode status 400 (Permintaan Buruk) menunjukkan bahwa server tidak dapat atau tidak akan memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien (misalnya, sintaks permintaan salah bentuk, pembingkaian pesan permintaan tidak valid, atau perutean permintaan yang menipu).

Karena permintaan berisi nilai duplikat (nilai yang sudah ada), itu dapat dianggap sebagai kesalahan klien. Perlu mengubah permintaan sebelum percobaan berikutnya.
Dengan mempertimbangkan fakta-fakta ini kita dapat menyimpulkan sebagai Permintaan Buruk HTTP STATUS 400.

Mohammed Safeer
sumber
1
Permintaan Buruk berarti bahwa ada masalah inheren dengan sintaks paket. Jika, dalam konteks lain (seperti sumber daya yang belum ada), paket tersebut akan berhasil, maka paket tersebut tidak akan mengembalikan kesalahan 400.
Grant Gryczan
1

Bagaimana dengan 208 - http://httpstatusdogs.com/208-al sudah- dilaporkan ? Apakah itu pilihan?

Menurut pendapat saya, jika satu-satunya hal adalah sumber daya yang berulang tidak ada kesalahan yang harus diajukan. Lagi pula, tidak ada kesalahan pada sisi klien atau server.

Fernando Ferreira
sumber
Ini bukan opsi karena Anda ingin menambahkan item tertentu yang id sudah ada. Jadi Anda mencoba menambahkan sesuatu tetapi ini sudah ada. OK akan berlaku hanya jika set data tumbuh. Tambah Sesuatu -> Ok Saya tidak menambahkan apa pun. Tidak cocok, kurasa.
Martin Kersten
Seperti yang saya katakan, saya tidak berpikir ini adalah kesalahan. Tapi saya melihat titik @martin
Fernando Ferreira
Jika sumber daya tidak berhasil dibuat, maka ada definisi kesalahan.
Grant Gryczan
POST juga digunakan untuk menambahkan data. Ini menurut definisi , bukan kesalahan .
Suncat2000
@ Suncat2000 Bahkan mengingat itu masalahnya, jika data tidak berhasil ditambahkan, masih ada kesalahan. Dan jika sumber daya sudah ada, tidak ada data yang akan ditambahkan.
Grant Gryczan
0

Dalam kasus Anda, Anda dapat menggunakan 409 Conflict

Dan jika Anda ingin memeriksa yang lain HTTPs kode status dari daftar di bawah ini

1 × × Informasional

100 Continue
101 Switching Protocols
102 Processing

2 × × Sukses

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3 × × Pengalihan

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

4 × × Kesalahan Klien

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

5 × × Kesalahan Server

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error
Abd Abughazaleh
sumber