Pertanyaan Alternatif yang Menyenangkan untuk MENGHAPUS Badan Permintaan


Selagi Spesifikasi HTTP 1.1 kelihatannya mengizinkan badan pesan di MENGHAPUS permintaan, tampaknya menunjukkan bahwa server harus mengabaikannya karena tidak ada semantik yang ditentukan untuk itu.

4.3 Isi Pesan

Sebuah server HARUS membaca dan meneruskan pesan-tubuh pada setiap permintaan; jika   metode permintaan tidak termasuk semantik yang ditentukan untuk entitas-tubuh,   maka isi pesan HARUS diabaikan ketika menangani permintaan.

Saya sudah meninjau beberapa diskusi terkait tentang topik ini di SO dan seterusnya, seperti:

Sebagian besar diskusi tampaknya setuju bahwa menyediakan badan pesan pada DELETE mungkin diizinkan, tetapi umumnya tidak disarankan.

Lebih lanjut, saya telah memperhatikan tren di berbagai pustaka klien HTTP di mana semakin banyak peningkatan tampaknya akan dicatat untuk pustaka ini guna mendukung badan permintaan pada DELETE. Sebagian besar perpustakaan tampaknya mengharuskan, meskipun kadang-kadang dengan sedikit perlawanan awal.

Kasus penggunaan saya panggilan untuk penambahan beberapa metadata yang diperlukan pada DELETE (misalnya "alasan" untuk penghapusan, bersama dengan beberapa metadata lain yang diperlukan untuk penghapusan). Saya telah mempertimbangkan opsi berikut, tidak ada yang tampaknya benar-benar sesuai dan sesuai dengan spesifikasi HTTP dan / atau praktik terbaik REST:

  • Badan Pesan - Spesifikasi menunjukkan bahwa isi pesan pada DELETE tidak memiliki nilai semantik; tidak sepenuhnya didukung oleh klien HTTP; bukan praktik standar
  • Header HTTP Kustom - Biasanya membutuhkan header khusus terhadap praktik standar; menggunakan mereka tidak konsisten dengan sisa API saya, tidak ada yang memerlukan header khusus; lebih lanjut, tidak ada respons HTTP yang baik yang tersedia untuk menunjukkan nilai header khusus yang buruk (mungkin pertanyaan terpisah sama sekali)
  • Header HTTP Standar - Tidak ada header standar yang sesuai
  • Parameter Kueri - Menambahkan params kueri sebenarnya mengubah URI Permintaan yang dihapus; terhadap praktik standar
  • Metode POST - (mis. POST /resourceToDelete { deletemetadata }) POST bukan pilihan semantik untuk menghapus; POST sebenarnya mewakili seberang tindakan yang diinginkan (yaitu POST menciptakan sumber daya bawahan; tetapi saya harus menghapus sumber daya)
  • Berbagai Metode - Memisahkan permintaan DELETE menjadi dua operasi (misalnya PUT menghapus metadata, lalu DELETE) membagi operasi atom menjadi dua, berpotensi meninggalkan keadaan yang tidak konsisten. Alasan penghapusan (dan metadata terkait lainnya) bukan bagian dari representasi sumber daya itu sendiri.

Preferensi pertama saya mungkin akan menggunakan badan pesan, kedua ke header HTTP khusus; namun, seperti yang ditunjukkan, ada beberapa kerugian pada pendekatan ini.

Apakah ada rekomendasi atau praktik terbaik yang sejalan dengan standar REST / HTTP untuk menyertakan metadata yang diperlukan seperti itu pada permintaan DELETE? Apakah ada alternatif lain yang belum saya pertimbangkan?


76
2018-01-14 17:45


asal


Jawaban:


Meskipun beberapa rekomendasi tidak menggunakan badan pesan untuk permintaan DELETE, pendekatan ini mungkin tepat dalam kasus penggunaan tertentu. Ini adalah pendekatan yang akhirnya kami gunakan setelah mengevaluasi opsi lain yang disebutkan dalam pertanyaan / jawaban, dan setelah berkolaborasi dengan konsumen layanan.

Meskipun penggunaan badan pesan tidak ideal, tidak ada opsi lain yang juga pas. Badan permintaan DELETE memungkinkan kami dengan mudah dan jelas menambahkan semantik di sekitar data tambahan / metadata yang diperlukan untuk mendampingi operasi DELETE.

Saya masih terbuka untuk pemikiran dan diskusi lain, tetapi ingin menutup lingkaran pada pertanyaan ini. Saya menghargai pemikiran dan diskusi semua orang tentang topik ini!


35
2018-03-18 16:36



Apa yang Anda inginkan adalah salah satu dari dua hal, yang keduanya tidak murni DELETE:

  1. Anda memiliki dua operasi, Sebuah PUT dari alasan penghapusan diikuti oleh DELETE sumber daya. Setelah dihapus, konten sumber daya tidak lagi dapat diakses oleh siapa pun. 'Alasan' tidak dapat berisi hyperlink ke sumber daya yang dihapus. Atau,
  2. Anda mencoba mengubah sumber daya dari state=active untuk state=deleted dengan menggunakan DELETE metode. Sumber daya dengan status = dihapus diabaikan oleh API utama Anda tetapi mungkin masih dapat dibaca oleh admin atau seseorang dengan akses basis data. Ini diizinkan - DELETE tidak perlu menghapus data backing untuk sumber daya, hanya untuk menghapus sumber daya yang terpapar pada URI tersebut.

Operasi apa pun yang memerlukan badan pesan di DELETE permintaan dapat dipecah menjadi paling umum, a POST untuk melakukan semua tugas yang diperlukan dengan isi pesan, dan a DELETE. Saya tidak melihat alasan untuk memecahkan semantik HTTP.


10
2018-01-15 09:10



Mengingat situasi yang Anda miliki, saya akan mengambil salah satu pendekatan berikut:

  • Kirim PUT atau PATCH: Saya menyimpulkan bahwa operasi penghapusan bersifat virtual, karena sifatnya perlu alasan penghapusan. Oleh karena itu, saya percaya memperbarui catatan melalui operasi PUT / PATCH adalah pendekatan yang valid, meskipun itu bukan operasi DELETE per se.
  • Gunakan parameter kueri: Sumber daya uri tidak sedang diubah. Saya benar-benar berpikir ini juga merupakan pendekatan yang valid. Pertanyaan yang Anda tautkan berbicara tentang tidak mengizinkan penghapusan jika parameter kueri hilang. Dalam kasus Anda, saya hanya akan memiliki alasan default jika alasannya tidak ditentukan dalam string kueri. Sumber daya akan tetap resource/:id. Anda dapat membuatnya dapat ditemukan dengan header Taut pada sumber daya untuk setiap alasan (dengan rel beri tanda pada masing-masing untuk mengidentifikasi alasannya).
  • Gunakan titik akhir yang terpisah untuk setiap alasan: Menggunakan url seperti resource/:id/canceled. Ini benar-benar mengubah Request-URI dan pasti tidak RESTful. Sekali lagi, header tautan dapat membuat ini dapat ditemukan.

Ingat bahwa REST bukan hukum atau dogma. Anggap saja lebih sebagai panduan. Jadi, ketika masuk akal untuk tidak mengikuti panduan untuk domain masalah Anda, jangan. Pastikan saja konsumen API Anda diberitahu tentang variasinya.


6
2018-01-15 05:37



Saya sarankan Anda menyertakan metadata yang diperlukan sebagai bagian dari hirarki URI itu sendiri. Contoh (Naive):

Jika Anda perlu menghapus entri berdasarkan rentang tanggal, daripada melewatkan tanggal mulai dan tanggal akhir dalam tubuh atau sebagai parameter kueri, susun URI sedemikian rupa sehingga Anda menyampaikan informasi yang diperlukan sebagai bagian dari URI.

misalnya

DELETE /entries/range/01012012/31122012 - Hapus semua entri antara 01 Januari 2012 hingga 31 Desember 2012

Semoga ini membantu.


0
2018-01-15 07:07