Panggilan REST PUT / POST / DELETE apa yang harus dikembalikan oleh konvensi?

153

  1. Menurut "ideologi REST", apa yang seharusnya ada di badan respons untuk permintaan PUT / POST / HAPUS?

  2. Bagaimana dengan kode pengembalian? Apakah HTTP_OKcukup?

  3. Apa alasan konvensi semacam itu, jika ada?

Saya telah menemukan postingan yang bagus yang menggambarkan perbedaan POST / PUT: POST vs PUT Tetapi masih belum menjawab pertanyaan saya.

rest http post http-delete tuxSlayer
sumber

Jawaban:

130

Maafkan kelemahan ini, tetapi jika Anda melakukan REST melalui HTTP maka RFC7231 menjelaskan dengan tepat perilaku apa yang diharapkan dari GET, PUT, POST dan DELETE.

Pembaruan (3 Juli '14):
Spec HTTP sengaja tidak mendefinisikan apa yang dikembalikan dari POST atau DELETE. Spesifikasi hanya mendefinisikan apa yang perlu didefinisikan. Sisanya diserahkan kepada pelaksana untuk memilih.

Darrel Miller
sumber
9
@tuxslayer Saya senang Anda tidak berpikir saya hanya mencoba untuk menjadi snarky. Banyak orang tampaknya berpikir REST menambahkan persyaratan tambahan di atas metode HTTP. Namun, bukan itu masalahnya. Ada kendala tambahan tetapi mereka tidak benar-benar mempengaruhi perilaku metode HTTP. RFC2616 jelas merupakan panduan untuk diikuti.
Darrel Miller
4
Saya menghargai tautannya. :) Itu membuat saya berhenti dan berpikir tentang alat yang saya gunakan. Setelah membaca posting Anda, dan RFC, saya menemukan diri saya merujuk pada RFC sepanjang malam. Ini membantu saya memikirkan proses sebagai proses HTTP terlebih dahulu, dan proses sisanya kedua. Sangat dihargai.
Perry Tew
4
@PerryTew Sekarang Anda bisa pergi ke sini tools.ietf.org/wg/httpbis dan lihat versi HTTP spec yang saat ini sedang direvisi. Nikmati!
Darrel Miller
12
Mungkin saya hanya perlu tidur lebih banyak, tetapi sepertinya saya tidak dapat menemukan informasi persis yang diminta OP dalam RFC. Bagaimana seharusnya tubuh untuk respons POST atau HAPUS?
Cam Jackson
9
Ya, itu sejelas lumpur. Mungkin lebih banyak informasi dalam jawaban akan membantu. Terutama, ketika tautan itu mati.
Doug Molineux
25

Secara keseluruhan, konvensi ini “berpikir seperti Anda hanya memberikan halaman web”.

Untuk PUT, saya akan mengembalikan tampilan yang sama dengan yang Anda dapatkan jika Anda melakukan GET segera setelah itu; itu akan menghasilkan 200 (well, dengan asumsi rendering berhasil tentu saja). Untuk POST, saya akan melakukan redirect ke sumber daya yang dibuat (dengan asumsi Anda melakukan operasi pembuatan; jika tidak, kembalikan hasilnya); kode untuk pembuatan yang berhasil adalah 201, yang merupakan satu-satunya kode HTTP untuk pengalihan yang tidak ada dalam kisaran 300.

Saya tidak pernah senang tentang apa yang harus dikembalikan DELETE (kode saya saat ini menghasilkan HTTP 204 dan badan kosong dalam kasus ini).

Donal Fellows
sumber
1
Memiliki PUTpermintaan kembali halaman berikutnya sepertinya praktik yang buruk, karena menyegarkan pada halaman yang dihasilkan akan menyebabkan permintaan untuk mengeksekusi lagi. Sebaliknya, bagi saya, masuk akal untuk melakukan pengalihan, dengan asumsi Anda sedang berurusan dengan permintaan sinkron.
lobati
1
@lobati Saya pikir penting untuk dicatat bahwa mengirim beberapa permintaan PUT yang identik, seharusnya memiliki hasil yang sama persis dengan mengirim hanya satu dari permintaan PUT yang sama. Mungkin masalah yang Anda angkat sekarang kurang penting mengingat hal di atas?
Iain
3
@ Aku tidak juga. Masalahnya adalah, jika sesuatu yang lain memperbarui catatan nanti, Anda tidak ingin mengirimkannya PUTpermintaan lain yang menyebabkan data dikembalikan. Misalnya, jika dua orang mereferensikan halaman yang sama, satu membuat pembaruan, lalu yang lain membuat pembaruan, jika orang pertama menyegarkan untuk melihat hasilnya, itu akan benar-benar menyebabkan hal-hal yang akan dikembalikan sebelum orang kedua membuat perubahan mereka.
lobati
"Think like website" sempurna, sehingga penghapusan dapat merespons dengan beberapa tindakan selanjutnya, yang tergantung pada "cerita" di sekitar mengapa Anda akan menghapus sumber daya. Setidaknya ini bisa berupa tautan untuk membawa agen kembali ke beberapa tempat tindakan logis awal, atau bahkan pengalihan ke sumber daya status yang menunjukkan dampak penghapusan (total pesanan) dan berisi tautan lebih lanjut.
Luke Puplett
3

Membuat sumber daya umumnya dipetakan ke POST, dan itu harus mengembalikan lokasi sumber daya baru; misalnya, dalam scaffold Rails CREATE akan mengalihkan ke SHOW untuk sumber daya yang baru dibuat. Pendekatan yang sama mungkin masuk akal untuk memperbarui (PUT), tetapi itu kurang konvensi; pembaruan hanya perlu menunjukkan keberhasilan. Penghapusan mungkin hanya perlu mengindikasikan keberhasilan juga; jika Anda ingin mengarahkan, mengembalikan daftar sumber daya mungkin paling masuk akal.

Keberhasilan dapat ditunjukkan oleh HTTP_OK, ya.

Satu-satunya aturan keras dan cepat dalam apa yang saya katakan di atas adalah bahwa BUAT harus mengembalikan lokasi sumber daya baru. Bagi saya itu sepertinya tidak ada artinya; sangat masuk akal bahwa klien harus dapat mengakses item baru.

Jacob Mattison
sumber
2
Anda sebenarnya telah mencampur PUT dan POST. POST digunakan untuk membuat, PUT digunakan untuk memperbarui (dan membuat). Penting juga untuk dicatat bahwa PUT harus idempoten sedangkan POST tidak.
Stevie
Perintah idempoten harus berfungsi dengan baik namun sering kali Anda menjalankannya. Jadi Anda harus dapat melakukan PUT yang sama beberapa kali untuk menerapkan "pembaruan" yang sama tanpa efek samping negatif.
Jacob Mattison
1

Oleh RFC7231 itu tidak masalah dan mungkin kosong

Bagaimana kami menerapkan solusi berbasis standar json api di proyek:

post / put: output atribut objek seperti pada get (filter bidang / hubungan berlaku sama)

delete: data hanya berisi null (untuk representasi objek yang hilang)

status untuk penghapusan standar: 200

Marius Gri
sumber
0

Saya suka Alfonso Tienda merespons dari kode status HTTP untuk memperbarui dan menghapus?

Berikut 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.

Ryabchenko Alexander
sumber