Saya telah mengizinkan penggantian grosir suatu koleksi, misalnya di PUT ~/people/123/shoesmana tubuh adalah representasi seluruh koleksi.
Ini berfungsi untuk koleksi anak kecil dari item di mana klien ingin meninjau item dan memangkas beberapa dan menambahkan beberapa lainnya dan kemudian memperbarui server. Mereka dapat MENEMPATKAN koleksi kosong untuk menghapus semua.
Ini berarti GET ~/people/123/shoes/9akan tetap ada dalam cache meskipun PUT menghapusnya, tetapi itu hanya masalah cache dan akan menjadi masalah jika beberapa orang lain menghapus sepatu tersebut.
API data / sistem saya selalu menggunakan ETag sebagai lawan dari waktu kedaluwarsa sehingga server terkena setiap permintaan, dan saya memerlukan header versi / konkurensi yang benar untuk mengubah data. Untuk API yang hanya-baca dan tampilan / laporan selaras, saya menggunakan waktu kedaluwarsa untuk mengurangi klik pada asal, misalnya papan peringkat bisa berlangsung selama 10 menit.
Untuk koleksi yang jauh lebih besar, seperti ~/people, saya cenderung tidak memerlukan banyak penghapusan, kasus penggunaan cenderung tidak muncul secara alami dan DELETE tunggal berfungsi dengan baik.
Di masa depan, dan dari pengalaman dengan membangun REST API dan mencapai masalah dan persyaratan yang sama, seperti audit, saya cenderung hanya menggunakan kata kerja GET dan POST dan desain di sekitar peristiwa, misalnya POST peristiwa perubahan alamat, meskipun saya curiga bahwa akan datang dengan masalah tersendiri :)
Saya juga akan mengizinkan pengembang front-end untuk membangun API mereka sendiri yang menggunakan API back-end yang lebih ketat karena seringkali ada alasan sisi klien yang valid dan praktis mengapa mereka tidak menyukai desain REST API "Fielding fanatik" yang ketat, dan untuk produktivitas dan alasan pelapisan cache.