Kode status apa yang harus saya tetapkan untuk UPDATE( PUT) dan DELETE(mis. Produk berhasil diperbarui)?
Kode status HTTP untuk memperbarui dan menghapus?
Jawaban:
Untuk permintaan PUT : HTTP 200 atau HTTP 204 harus menyiratkan "sumber daya berhasil diperbarui".
Untuk permintaan DELETE : HTTP 200 atau HTTP 204 harus menyiratkan "sumber daya berhasil dihapus". HTTP 202 juga dapat dikembalikan yang akan menyiratkan bahwa instruksi diterima oleh server dan "sumber daya ditandai untuk dihapus".
Jika sumber daya yang ada diubah, baik kode respons 200 (OK) atau 204 (Tidak Ada Konten)> HARUS dikirim untuk mengindikasikan keberhasilan penyelesaian permintaan.
Respons yang berhasil HARUS menjadi 200 (OK) jika respons mencakup entitas yang menggambarkan status, 202 (Diterima) jika tindakan belum diberlakukan, atau 204 (Tidak Ada Konten) jika tindakan telah diberlakukan tetapi respons tidak termasuk sebuah entitas.
Sumber: W3.org: Definisi Metode HTTP / 1.1
HTTP 200 OK: Respons standar untuk permintaan HTTP yang berhasil. Respons aktual akan bergantung pada metode permintaan yang digunakan.
HTTP 204 Tidak Ada Konten: Server berhasil memproses permintaan, tetapi tidak mengembalikan konten apa pun
40
Posting yang sangat berguna! Namun saya bertanya-tanya apa yang seharusnya menjadi kode status HTTP adalah permintaan yang dikirim oleh klien valid (HAPUS mySite / entitas / 123 ) dan entitas yang akan dihapus tidak ada.
—
Martin
@ Martin: Dalam hal ini, layanan harus mengembalikan HTTP 404. Sebenarnya, DELETE atau permintaan GET untuk sumber daya yang tidak ada bukanlah permintaan yang "valid" - yaitu. klien tidak boleh mencoba lagi permintaan itu karena itu tidak akan pernah berhasil ... Protokol HTTP mendefinisikan 2 kategori masalah - masalah dengan kode status 4xx, di mana klien harus memodifikasi permintaan sebelum mencoba lagi, dan yang dengan status 5xx kode, yang menunjukkan bahwa layanan mengalami masalah dan klien harus / bisa mencoba lagi permintaan yang sama tanpa mengubahnya.
—
Daniel Vassallo
@JeffMartin Itu mungkin begitu dari sudut pandang pengguna, tetapi sejauh menyangkut server, jika sumber daya tidak ada, server harus mengembalikan 404.
—
Randolpho
@Randolpho, Idempotence adalah tentang mendapatkan hasil yang sama apakah Anda menjalankan operasi satu kali atau beberapa kali. Klien meminta Anda untuk memastikan bahwa sumber daya dihapus. Apa manfaat mengembalikan 404? Mengapa perlu tahu cara baik? Sekarang logika klien harus menangani dua kode respons yang terpisah, bukan satu.
—
Gili
@Gili: mungkin wiki akan menjelaskan lebih baik: Metode PUT dan DELETE didefinisikan sebagai idempoten ... perhatikan bahwa idempoten mengacu pada keadaan sistem setelah permintaan selesai, jadi ketika tindakan yang diambil server (misalnya menghapus catatan) ) atau kode respons yang dikembalikan mungkin berbeda pada permintaan berikutnya, status sistem akan sama setiap waktu.
—
Randolpho
Jawaban singkat: untuk PUT dan DELETE, Anda harus mengirim 200 (OK) atau 204 (Tidak Ada Konten).
Jawaban panjang: inilah diagram keputusan lengkap (klik untuk memperbesar).
Diagram ini luar biasa. Apakah ada versi resolusi yang lebih tinggi untuk dicetak?
—
KiKi
Dalam konteks POST dari sumber daya yang ada, diskusi SO lainnya ( stackoverflow.com/questions/3825990/… ) menyarankan untuk mengirim 409 Konflik atau 302 Ditemukan alih-alih menambahkan konten.
—
koppor
Saya ingin tahu apakah respons 204 dan 200 setelah penghapusan terjadi harus dibalik, dan jika benar, mengapa? Dihapus? -> Tanggapan termasuk entitas? -> ya -> 204 Tidak Ada Konten; tidak -> 200 OK
—
matth
Versi terbaru dari gambar ada di sini: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
Tidak ada PATCH.
—
doremi
Inilah beberapa Tips:
MENGHAPUS
200 (jika Anda ingin mengirim beberapa data tambahan dalam Respons) atau 204 (disarankan).
202 Operasi yang dihapus belum dilakukan.
Jika tidak ada yang dihapus, gunakan 204 atau 404 (Operasi HAPUS idempoten, hapus item yang sudah dihapus berhasil operasi , sehingga Anda dapat mengembalikan 204 , tetapi memang benar bahwa idempoten tidak selalu menyiratkan respons yang sama)
Kesalahan lain:
- 400 Bad Request (Sintaks salah format atau kueri buruk aneh tapi mungkin).
- 401 Kegagalan otentikasi tidak sah
- 403 Forbidden : Kegagalan otorisasi atau ID Aplikasi tidak valid.
- 405 Tidak Diizinkan . Tentu.
- 409 Konflik Sumber Daya dapat dimungkinkan dalam sistem yang kompleks.
- Dan 501 , 502 jika terjadi kesalahan.
TARUH
Jika Anda memperbarui elemen koleksi
- 200/204 dengan alasan yang sama seperti DELETE di atas.
- 202 jika operasi belum dilakukan.
Elemen yang dirujuk tidak ada:
- PUT bisa 201 (jika Anda membuat elemen karena itu adalah perilaku Anda)
404 Jika Anda tidak ingin membuat elemen melalui PUT.
400 Permintaan Buruk (Sintaks salah format atau kueri buruk lebih umum daripada dalam kasus DELETE).
- 401 Tidak Resmi
- 403 Forbidden : Kegagalan otentikasi atau ID Aplikasi tidak valid.
- 405 Tidak Diizinkan . Tentu.
- 409 Konflik Sumber Daya dapat dimungkinkan dalam sistem yang kompleks, seperti pada DELETE.
- 422 Entitas yang tidak dapat diproses Ini membantu untuk membedakan antara "Permintaan salah" (mis. XML / JSON yang salah bentuk) dan nilai bidang tidak valid
- Dan 501 , 502 jika terjadi kesalahan.
Jawaban ini hampir seluruhnya terdiri dari dua kutipan besar, tetapi tidak ada atribusi. Anda mengutip dari mana?
—
Quentin
Apakah 204 status yang tepat untuk dikembalikan untuk permintaan PUT, jika negara tidak diubah secara efektif? Misalnya, Anda meminta untuk menonaktifkan pengguna tetapi pengguna sudah tidak aktif.
—
Ε Г И І И О
Permintaan PUT idempoten, sehingga Anda dapat mengembalikan 204, karena objek telah berubah dalam sistem. PUT bukan PATCH, jadi Anda tidak yakin bidang apa yang ingin Anda ubah. Anda dapat mengirim kembali 501 - 502, jika desain Anda perlu tahu apakah objek itu persis sama dengan objek dalam permintaan tetapi ... Saya tidak terlalu menyukainya .. Saya lebih suka 204 atau, jika Anda ingin nonaktifkan pengguna, tanpa mengubah lebih banyak bidang, mungkin Anda dapat menggunakan PATCH.
—
Alfonso Tienda
Saya akan menambahkan HTTP 422 Entitas yang tidak dapat diproses. Ini membantu untuk membedakan antara "Permintaan salah" (mis. XML / JSON salah bentuk) dan nilai bidang tidak valid.
—
vdboor
RFC 2616 menjelaskan kode status mana yang digunakan .
Dan tidak, tidak selalu 200.
Selain 200 dan 204, 205 (Reset Konten) bisa menjadi respons yang valid.
Server telah memenuhi permintaan dan agen pengguna HARUS mengatur ulang tampilan dokumen yang menyebabkan permintaan untuk dikirim ... [misalnya] menghapus formulir di mana input diberikan.
Karena pertanyaannya menyelidiki apakah DELETE "harus" mengembalikan 200 vs 204 , ada baiknya mempertimbangkan bahwa beberapa orang merekomendasikan pengembalian entitas dengan tautan sehingga preferensi untuk 200 .
"Alih-alih mengembalikan 204 (Tanpa Konten), API harusnya membantu dan menyarankan tempat untuk dikunjungi. Dalam contoh ini saya pikir satu tautan yang jelas untuk diberikan adalah ke" 'somewhere.com/container/' (minus 'resource') "- wadah tempat klien baru saja menghapus sumber daya. Mungkin klien ingin menghapus lebih banyak sumber daya, sehingga akan menjadi tautan yang bermanfaat. "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
Jika klien menemukan respons 204, ia bisa menyerah, pergi ke titik masuk API, atau kembali ke sumber daya sebelumnya yang dikunjungi. Tidak ada pilihan yang baik.
Secara pribadi saya tidak akan mengatakan 204 salah (begitu pula penulisnya; ia mengatakan "menjengkelkan") karena caching yang baik di sisi klien memiliki banyak manfaat. Yang terbaik adalah konsisten.
Ini beberapa kode status, yang harus Anda ketahui untuk pengetahuan Anda.
Tanggapan Informasi 1XX
- 100 Lanjutkan
- 101 Protokol Pengalihan
- 102 Memproses
- 103 Petunjuk Awal
2XX Sukses
- 200 OK
- 201 Dibuat
- 202 Diterima
- 203 Informasi Non-Resmi
- 204 Tidak Ada Konten
- 205 Atur Ulang Konten
- 206 Konten Sebagian
- 207 Multi-Status
- 208 Sudah Dilaporkan
- 226 IM Digunakan
Pengalihan 3XX
- 300 Pilihan Ganda
- 301 Dipindahkan Secara Permanen
- 302 Ditemukan
- 303 Lihat Lainnya
- 304 Tidak Dimodifikasi
- 305 Gunakan Proxy
- 306 Beralih Proksi
- 307 Redirect Sementara
- 308 Pengalihan Permanen
Kesalahan 4XX Client
- 400 Permintaan Buruk
- 401 Tidak Resmi
- 402 Diperlukan Pembayaran
- 403 Dilarang
- 404 Tidak Ditemukan
- 405 Metode Tidak Diizinkan
- 406 Tidak Dapat Diterima
- Diperlukan 407 Otentikasi Proksi
- 408 Batas Waktu Permintaan
- 409 Konflik
- 410 Hilang
- 411 Panjang Diperlukan
- 412 Prasyarat Gagal
- 413 Payload Terlalu Besar
- 414 URI Terlalu Panjang
- 415 Jenis Media yang Tidak Didukung
- 416 Range Tidak Memuaskan
- 417 Harapan Gagal
- 418 Saya seorang teko
- 420 Kegagalan Metode
- 421 Permintaan Salah Arah
- 422 Entitas yang Tidak Dapat Diproses
- 423 Terkunci
- 424 Dependensi Gagal
- Diperlukan 426 Peningkatan
- Diperlukan 428 Prasyarat
- 429 Terlalu Banyak Permintaan
- 431 Bidang Judul Permintaan Terlalu Besar
- 451 Tidak Tersedia Untuk Alasan Hukum
5XX Kesalahan server
- 500 Galat Server Internal
- 501 Tidak Diimplementasikan
- 502 Gerbang Buruk
- 503 Layanan Tidak Tersedia
- 504 Timeout gerbang
- 505 Versi Http tidak didukung
- 506 Varient Juga bernegosiasi
- 507 Penyimpanan Tidak Memadai
- 508 Loop Terdeteksi
- 510 Tidak Diperpanjang
- 511 Diperlukan Otentikasi Jaringan
Ketika sumber daya diubah, kode respons harus 200 ("OK") . Jika keadaan sumber daya berubah dengan cara yang mengubah URI ke sumber daya (misalnya, akun pengguna diubah namanya), kode responsnya adalah 301 (“Dipindahkan Secara Permanen”) dan header Lokasi harus menyediakan URI yang baru.
Ketika suatu objek dihapus, kode responsnya harus 200 ("OK").
Ikuti tautan di bawah ini untuk detail lebih lanjut - kode status untuk istirahat