Vì vậy, cho rằng động từ DELETE trong Http là không có ý nghĩa, khi tôi đưa ra yêu cầu sau, điều gì sẽ xảy ra ở lần thứ hai (hoặc thứ ba, hoặc thứ tư, v.v.)?
DELETE /person/123
Lần đầu tiên, tài nguyên bị xóa và tôi trả về 204 (thành công, không có nội dung). Tôi nên trả lại số 204 trong các cuộc gọi tiếp theo hay số 404 (không tìm thấy)?
Câu trả lời:
Vì các yêu cầu HTTP trong một hệ thống không trạng thái phải độc lập, kết quả của một yêu cầu không được phụ thuộc vào yêu cầu trước đó. Hãy xem xét điều gì sẽ xảy ra nếu hai người dùng thực hiện XÓA trên cùng một tài nguyên đồng thời. Yêu cầu thứ hai nhận được 404. Điều này cũng đúng nếu một người dùng thực hiện hai yêu cầu.
Tôi đoán rằng việc DELETE trả về hai câu trả lời khác nhau không cảm thấy hữu ích cho bạn. Tôi thấy hữu ích khi nghĩ về các yêu cầu Idempotent là để hệ thống ở cùng một trạng thái, không nhất thiết phải có cùng một phản hồi. Vì vậy, bất kể bạn XÓA tài nguyên hiện có hay cố gắng XÓA tài nguyên không tồn tại, trạng thái tài nguyên máy chủ đều giống nhau.
rm. rmtrả về lỗi nếu nó không tồn tại. tools.ietf.org/html/rfc7231#section-4.3.5
Sách dạy nấu ăn của các dịch vụ web RESTful là một nguồn tài liệu tuyệt vời cho việc này. Tình cờ, bản xem trước trên google của nó hiển thị trang về DELETE (trang 11):
Phương thức DELETE là không quan trọng. Điều này ngụ ý rằng máy chủ phải trả về mã phản hồi 200 (OK) ngay cả khi máy chủ đã xóa tài nguyên trong một yêu cầu trước đó. Nhưng trên thực tế, việc triển khai DELETE như một hoạt động không cần thiết yêu cầu máy chủ phải theo dõi tất cả các tài nguyên đã xóa. Nếu không, nó có thể trả về 404 (Không tìm thấy).
Tôi đồng ý với những gì câu trả lời được chọn hiện tại đã nói, rằng DELETE thứ 2 (và thứ 3, thứ 4, ...) sẽ nhận được 404 . Và, tôi nhận thấy rằng câu trả lời có 143 lượt bình chọn nhưng cũng có một bình luận ngược lại có 54 lượt bình chọn trở lên, vì vậy cộng đồng được chia thành 2 phe theo tỷ lệ khoảng 3: 1. Ở đây có thêm thông tin để giải quyết cuộc tranh luận lâu dài này.
Trước hết, chúng ta hãy KHÔNG bắt đầu với những gì "tôi" nghĩ, những gì "bạn" nghĩ, hoặc những gì một tác giả cuốn sách khác nghĩ. Hãy bắt đầu với thông số kỹ thuật HTTP, tức là RFC 7231.
DELETE /some/resource/which/does/not/existsẽ dẫn đến 404. Sau đó, DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/agocũng có thể trả về 404 Sau đó, tại sao phải DELETE /some/resource/i/deleted/five/seconds/agokhác nhau? "Nhưng làm thế nào về tính đơn giản ?!", tôi có thể nghe thấy bạn đang hét lên rằng. Chờ đã, chúng tôi sắp đi vào vấn đề đó.Trong lịch sử, RFC 2616, được xuất bản vào năm 1999, là thông số kỹ thuật HTTP 1.1 được tham chiếu nhiều nhất. Thật không may, mô tả của nó về tính đơn giản rất mơ hồ , điều đó dành chỗ cho tất cả các cuộc tranh luận này. Nhưng thông số kỹ thuật đó đã được thay thế bởi RFC 7231. Trích dẫn từ RFC 7231, phần 4.2.2 Phương pháp Idempotent , tôi nhấn mạnh:
Một phương thức yêu cầu được coi là "idempotent" nếu TÁC DỤNG dự kiến TRÊN MÁY CHỦ của nhiều yêu cầu giống hệt nhau với phương thức đó giống như hiệu ứng đối với một yêu cầu như vậy. Trong số các phương thức yêu cầu được xác định bởi đặc tả này, PUT, DELETE và các phương thức yêu cầu an toàn là không quan trọng .
Vì vậy, nó được viết trong thông số kỹ thuật, tính đơn giản là tất cả về hiệu ứng trên máy chủ. DELETE đầu tiên trả về 204 và sau đó DELETE tiếp theo trả về 404, mã trạng thái khác nhau như vậy KHÔNG làm cho DELETE không phải là ý tưởng. Sử dụng đối số này để biện minh cho lần trả lại 204 tiếp theo, đơn giản là không thích hợp.
OK vì vậy nó không phải là về tính đơn giản. Nhưng sau đó một câu hỏi tiếp theo có thể là, nếu chúng ta vẫn chọn sử dụng 204 trong XÓA tiếp theo thì sao? Là nó ổn?
Câu hỏi hay. Động cơ có thể hiểu được: cho phép khách hàng vẫn đạt được kết quả dự kiến mà không cần lo lắng về việc xử lý lỗi. Tôi sẽ nói rằng, trả về 204 trong DELETE tiếp theo, là một "lời nói dối trắng" phía máy chủ phần lớn là vô hại, mà phía máy khách sẽ không nhận ra sự khác biệt ngay lập tức. Đó là lý do tại sao có ~ 25% người làm điều đó trong tự nhiên và nó dường như vẫn hoạt động. Chỉ cần lưu ý rằng, lời nói dối như vậy có thể được coi là kỳ lạ về mặt ngữ nghĩa, bởi vì GET /non-existtrả về 404 nhưng DELETE /non-existlại cho 204, tại thời điểm đó khách hàng sẽ nhận ra dịch vụ của bạn không hoàn toàn tuân thủ phần 6.5.4 404 Not Found .
Nhưng tôi muốn chỉ ra rằng, cách dự định được gợi ý bởi RFC 7231, tức là trả về 404 trong lần DELETE tiếp theo, không phải là một vấn đề ngay từ đầu. Có gấp 3 lần nhà phát triển chọn làm điều đó và bạn đã bao giờ nghe thấy một sự cố lớn hoặc phàn nàn do khách hàng không thể xử lý 404 chưa? Có lẽ, không, và đó là bởi vì, bất kỳ ứng dụng khách tốt nào triển khai HTTP DELETE (hoặc bất kỳ phương thức HTTP nào, cho vấn đề đó), sẽ không mù quáng cho rằng kết quả sẽ luôn là thành công 2xx. Và sau đó, khi nhà phát triển bắt đầu xem xét việc xử lý lỗi, 404 Not Found sẽ là một trong những lỗi đầu tiên xuất hiện trong tâm trí. Tại thời điểm đó, anh ấy / cô ấy có thể sẽ rút ra kết luận rằng, hoạt động HTTP DELETE bỏ qua lỗi 404 là an toàn về mặt ngữ nghĩa. Và họ đã làm như vậy.
Vấn đề đã được giải quyết.
XÓA đầu tiên : 200 hoặc 204.
Điểm XÓA Tiếp theo : 200 hoặc 204.
Cơ sở lý luận : DELETE phải là không quan trọng. Nếu bạn quay trở lại 404 trên DELETE thứ hai, phản ứng của bạn đang thay đổi từ một đang thành công với một mã lỗi . Chương trình khách hàng có thể thực hiện các hành động không chính xác dựa trên giả định việc XÓA không thành công.
Ví dụ :
Chỉ để minh họa việc sử dụng phương pháp này, hướng dẫn kiểu API HTTP cho PayPal có hướng dẫn sau:
DELETE: Phương thức này NÊN trả về mã trạng thái 204 vì không cần trả lại bất kỳ nội dung nào trong hầu hết các trường hợp vì yêu cầu xóa tài nguyên và nó đã được xóa thành công.
Vì phương thức DELETE cũng PHẢI là idmpotent, nên nó vẫn NÊN trả về 204, ngay cả khi tài nguyên đã bị xóa. Thông thường, người tiêu dùng API không quan tâm xem tài nguyên đã bị xóa như một phần của hoạt động này hay trước đó. Đây cũng là lý do tại sao 204 thay vì 404 nên được trả về.