Pertanyaan Kode status HTTP untuk memperbarui dan menghapus?


Kode status apa yang harus saya atur UPDATE (PUT) dan DELETE (misalnya produk berhasil diperbarui)?


992
2018-02-26 15:16


asal


Jawaban:


Untuk sebuah TARUH permintaan: HTTP 200 atau HTTP 204 harus menyiratkan "sumber daya berhasil diperbarui".

Untuk sebuah MENGHAPUS permintaan: HTTP 200 atau HTTP 204 harus menyiratkan "sumber daya berhasil dihapus". HTTP 202 juga dapat dikembalikan yang akan menyiratkan bahwa instruksi itu diterima oleh server dan "sumber daya ditandai untuk dihapus".

9,6 PUT

Jika sumber daya yang ada dimodifikasi, apakah kode tanggapan 200 (OK) atau 204 (Tanpa Konten)> HARUS dikirim untuk menunjukkan bahwa permintaan telah berhasil diselesaikan.

9.7 HAPUS

Tanggapan yang sukses SEHARUSNYA menjadi 200 (OK) jika respons mencakup entitas yang menjelaskan status, 202 (Diterima) jika tindakan belum diberlakukan, atau 204 (Tanpa Konten) jika tindakan telah diberlakukan tetapi tanggapan tidak termasuk sebuah entitas.

Sumber: w3.org: Definisi Metode HTTP / 1.1

HTTP 200 OK: Respons standar untuk HTTP yang berhasil   permintaan. Respons yang sebenarnya akan terjadi   tergantung pada metode permintaan yang digunakan.

HTTP 204 Tanpa Konten: Server berhasil memproses permintaan, tetapi tidak mengembalikan konten apa pun

Sumber: Daftar kode status HTTP: 2xx Sukses


1543
2018-02-26 15:18



Jawaban singkat: untuk PUT dan DELETE, Anda harus mengirim 200 (OK) atau 204 (Tanpa Konten).

Jawaban panjang: inilah diagram keputusan lengkap (klik untuk memperbesar).

HTTP 1.1 decision diagram

Sumber: https://github.com/for-GET/http-decision-diagram


717
2018-02-26 15:23



Berikut beberapa Tips:

MENGHAPUS

  • 200 (jika Anda ingin mengirim beberapa data tambahan di Respons) atau 204 (disarankan).

  • 202 Operasi yang dihapus belum dilakukan.

  • Jika tidak ada yang perlu dihapus, gunakan 204  atau  404 (Operasi DELETE adalah idempoten, hapus item yang sudah dihapus operasi sukses, jadi Anda dapat kembali 204, tapi memang benar bahwa idempoten tidak selalu berarti tanggapan yang sama)

Kesalahan lainnya:

  • 400  Permintaan yang buruk (Sintaks salah atau kueri buruk aneh tapi mungkin).
  • 401  Tidak sah Kegagalan autentikasi
  • 403  Terlarang: Kegagalan otorisasi atau ID Aplikasi yang tidak valid.
  • 405  Tidak Diizinkan. Yakin.
  • 409  Konflik Sumber Daya dapat dimungkinkan dalam sistem yang kompleks.
  • Dan 501, 502 jika ada kesalahan.

TARUH

Jika Anda memperbarui elemen koleksi

  • 200/204 dengan alasan yang sama seperti DELETE di atas.
  • 202 jika operasi belum dilakukan.

Elemen yang direferensikan 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 yang buruk (Sintaks salah atau kueri buruk lebih umum daripada dalam kasus DELETE).

  • 401  Tidak sah 
  • 403  Terlarang: Kegagalan autentikasi atau ID Aplikasi yang tidak valid.
  • 405  Tidak Diizinkan. Yakin.
  • 409  Konflik Sumber Daya dapat dimungkinkan dalam sistem yang kompleks, seperti pada DELETE.
  • 422  Entitas yang tidak dapat diproses Ini membantu membedakan antara "Permintaan buruk" (misalnya format XML / JSON) dan nilai bidang yang tidak valid
  • Dan 501, 502 jika ada kesalahan.

105
2017-09-24 12:14



RFC 2616 menjelaskan kode status mana yang akan digunakan.

Dan tidak, itu tidak selalu 200.


13
2018-02-26 15:20



Selain 200 dan 204, 205 (Setel Ulang Konten) bisa menjadi respon yang valid.

Server telah memenuhi permintaan dan agen pengguna HARUS menyetel ulang tampilan dokumen yang menyebabkan permintaan dikirim ... [mis.] Menghapus formulir di mana masukan diberikan.


7
2018-01-08 21:15



Karena pertanyaan itu menyelidiki apakah MENGHAPUS "harus" kembali 200 vs 204 ada baiknya mempertimbangkan bahwa beberapa orang menyarankan untuk mengembalikan entitas dengan tautan, sehingga pilihannya adalah untuk 200.

"Daripada mengembalikan 204 (Tanpa Konten), API harus membantu dan   menyarankan tempat untuk pergi. Dalam contoh ini saya pikir satu tautan yang jelas   berikan adalah untuk " 'somewhere.com/container/' (minus 'sumber') "- wadah dari mana   klien baru saja menghapus sumber daya. Mungkin keinginan klien   hapus lebih banyak sumber daya, jadi itu akan menjadi tautan yang bermanfaat. "

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Jika seorang klien menemui respons 204, ia dapat menyerah, pergi ke   titik masuk API, atau kembali ke sumber sebelumnya   dikunjungi. Tidak ada pilihan yang sangat bagus.

Secara pribadi saya tidak akan mengatakan 204 salah (begitu juga penulis; ia mengatakan "menjengkelkan") karena caching yang baik di sisi klien memiliki banyak manfaat. Yang terbaik adalah konsisten dengan cara apa pun.


6
2018-05-29 02:02



Pada Juni 2014 RFC7231 obsoletes RFC2616. Jika Anda melakukan REST melalui HTTP, maka RFC7231 menjelaskan dengan tepat perilaku apa yang diharapkan dari GET, PUT, POST, dan DELETE


2
2017-11-22 15:52



Ketika sumber daya diubah, kode respon seharusnya 200 ("OK"). Jika status sumber daya berubah dengan cara yang mengubah URI ke sumber daya (misalnya, akun pengguna diubah namanya), kode respons adalah 301 (“Dipindahkan Secara Permanen”) dan tajuk Lokasi harus menyediakan URI baru.

Ketika suatu objek dihapus, kode respon harus 200 ("OK").

Ikuti tautan di bawah ini untuk detail lebih lanjut - kode status untuk beristirahat


0
2017-12-26 07:51