Tôi đã cho phép thay thế bán buôn một bộ sưu tập, ví dụ như PUT ~/people/123/shoestrong đó phần thân là toàn bộ đại diện bộ sưu tập.
Điều này hoạt động đối với các bộ sưu tập nhỏ của các mục trong đó khách hàng muốn xem lại các mục và cắt bỏ một số và thêm một số mục khác vào rồi cập nhật máy chủ. Họ có thể PUT một tập hợp trống để xóa tất cả.
Điều này có nghĩa là GET ~/people/123/shoes/9sẽ vẫn còn trong bộ nhớ cache mặc dù PUT đã xóa nó, nhưng đó chỉ là vấn đề bộ nhớ đệm và sẽ là vấn đề nếu một số người khác xóa giày.
Các API dữ liệu / hệ thống của tôi luôn sử dụng ETags thay vì thời gian hết hạn, do đó máy chủ bị truy cập theo từng yêu cầu và tôi yêu cầu tiêu đề phiên bản / đồng thời chính xác để thay đổi dữ liệu. Đối với các API được căn chỉnh ở chế độ chỉ đọc và chế độ xem / báo cáo, tôi sử dụng thời gian hết hạn để giảm số lần truy cập vào nguồn gốc, ví dụ: bảng xếp hạng có thể tốt trong 10 phút.
Đối với các bộ sưu tập lớn hơn nhiều, chẳng hạn như ~/people, tôi có xu hướng không cần xóa nhiều lần, trường hợp sử dụng có xu hướng không tự nhiên phát sinh và vì vậy XÓA duy nhất hoạt động tốt.
Trong tương lai, và từ kinh nghiệm xây dựng các API REST và giải quyết các vấn đề và yêu cầu tương tự, như kiểm toán, tôi có xu hướng chỉ sử dụng các động từ GET và POST và thiết kế xung quanh các sự kiện, ví dụ: ĐĂNG một sự kiện thay đổi địa chỉ, mặc dù tôi nghi ngờ rằng sẽ đi kèm với một loạt vấn đề của riêng nó :)
Tôi cũng sẽ cho phép các nhà phát triển front-end xây dựng các API của riêng họ sử dụng các API back-end chặt chẽ hơn vì thường có những lý do thực tế, hợp lệ từ phía khách hàng khiến họ không thích các thiết kế API REST "Fielding zealot" nghiêm ngặt và vì năng suất và lý do phân lớp bộ nhớ cache.