REST, HTTP DELETE và các tham số

Có bất cứ điều gì không RESTful về việc cung cấp các tham số cho yêu cầu XÓA HTTP không?

Kịch bản của tôi là tôi đang lập mô hình "Bạn có chắc chắn muốn xóa nó không?" kịch bản. Trong một số trường hợp, trạng thái của tài nguyên cho thấy việc xóa được yêu cầu có thể không hợp lệ. Bạn có thể tự mình tưởng tượng một số tình huống trong đó yêu cầu xác nhận xóa

Giải pháp chúng tôi đã áp dụng là chuyển một tham số cho yêu cầu xóa để chỉ ra rằng bạn có thể tiến hành xóa ("? Force_delete = true")

ví dụ

DELETE http://server/resource/id?force_delete=true

Tôi tin rằng nó vẫn còn yên tĩnh kể từ:

(a) Các ngữ nghĩa của XÓA không bị thay đổi - người dùng vẫn có thể gửi yêu cầu XÓA bình thường nhưng điều này có thể thất bại với 409 và phần thân của phản hồi sẽ giải thích lý do. Tôi nói có thể thất bại bởi vì (vì lý do không đáng để giải thích) trong một số trường hợp không có lý do để nhắc nhở người dùng.

(b) Không có gì trong luận án của Roy để đề xuất rằng nó trái với tinh thần của REST - tại sao lại có vì HTTP chỉ là một triển khai của REST, vậy tại sao việc truyền các tham số HTTP lại quan trọng

Ai đó có thể chỉ cho tôi một tuyên bố dứt khoát rằng lý do tại sao điều này không phải là RESTful?

Đối với một câu hỏi liên quan, nếu người dùng không chỉ định Force_delete thì tôi sẽ trả lại 409 Conflict- đó có phải là mã phản hồi phù hợp nhất không?

Theo sát

Sau một số nghiên cứu sâu hơn, tôi nghĩ rằng việc thêm các tham số vào XÓA có thể vi phạm một số nguyên tắc.

Đầu tiên là việc triển khai có thể vi phạm "Giao diện thống nhất" (xem phần 5.1.5 của luận án của Roy

Bằng cách thêm 'force_delete', chúng tôi sẽ thêm một ràng buộc bổ sung vào phương thức XÓA đã được xác định rõ. Hạn chế này chỉ có ý nghĩa đối với chúng tôi.

Bạn cũng có thể lập luận rằng nó vi phạm "5.1.2 Máy khách-Máy chủ" do cuộc đối thoại xác nhận thực sự là mối quan tâm của UI và một lần nữa không phải tất cả khách hàng sẽ muốn xác nhận xóa.

Gợi ý cho ai?

Không, nó không phải là RESTful. Lý do duy nhất tại sao bạn nên đặt một động từ ( force_delete) vào URI là nếu bạn cần quá tải các phương thức GET / POST trong môi trường không có phương thức PUT / DELETE. Đánh giá từ việc bạn sử dụng phương pháp XÓA, đây không phải là trường hợp.

Mã lỗi HTTP 409/Conflictnên được sử dụng cho các tình huống có xung đột ngăn dịch vụ RESTful thực hiện thao tác, nhưng vẫn có khả năng người dùng có thể tự giải quyết xung đột. Một xác nhận xóa trước (trong đó không có xung đột thực sự sẽ ngăn chặn xóa) không phải là xung đột vì sẽ không có gì ngăn API thực hiện thao tác được yêu cầu.

Như Alex đã nói (tôi không biết ai đã hạ thấp anh ta, anh ta đúng), điều này nên được xử lý trong UI, bởi vì một dịch vụ RESTful như vậy chỉ xử lý các yêu cầu và do đó không nên dựa vào xác nhận bằng cách giữ bất kỳ thông tin phía máy chủ nào về yêu cầu).

Hai ví dụ về cách thực hiện điều này trong UI sẽ là:

• tiền HTML5 : * hiển thị hộp thoại xác nhận JS cho người dùng và chỉ gửi yêu cầu nếu người dùng xác nhận nó
• HTML5 : * sử dụng biểu mẫu với hành động XÓA trong đó biểu mẫu chỉ chứa các nút "Xác nhận" và "Hủy" ("Xác nhận" sẽ là nút gửi)

(*) Xin lưu ý rằng các phiên bản HTML trước 5 không hỗ trợ các phương thức HTTP PUT và DELETE, tuy nhiên hầu hết các trình duyệt hiện đại có thể thực hiện hai phương thức này thông qua các cuộc gọi AJAX. Xem chủ đề này để biết chi tiết về hỗ trợ trình duyệt chéo.

Cập nhật (dựa trên điều tra và thảo luận bổ sung):

Kịch bản trong đó dịch vụ sẽ yêu cầu xuất hiện force_delete=truecờ vi phạm giao diện thống nhất như được định nghĩa trong luận án của Roy Fielding. Ngoài ra, theo HTTP RFC , phương thức DELETE có thể bị ghi đè trên máy chủ gốc (máy khách), ngụ ý rằng điều này không được thực hiện trên máy chủ đích (dịch vụ).

Vì vậy, một khi dịch vụ nhận được yêu cầu XÓA, nó sẽ xử lý nó mà không cần bất kỳ xác nhận bổ sung nào (bất kể dịch vụ có thực sự hoạt động hay không).

Tôi nghĩ rằng điều này là không nghỉ ngơi. Tôi không nghĩ rằng dịch vụ nghỉ ngơi nên xử lý yêu cầu buộc người dùng xác nhận xóa. Tôi sẽ xử lý việc này trong UI.

Việc chỉ định Force_delete = true có hợp lý không nếu đây là API của chương trình? Nếu ai đó đang viết một tập lệnh để xóa tài nguyên này, bạn có muốn buộc họ chỉ định Force_delete = true để thực sự xóa tài nguyên không?

Đây là một câu hỏi cũ, nhưng đây là một số ý kiến ​​...

1. Trong SQL, lệnh DELETE chấp nhận tham số "CASCADE", cho phép bạn chỉ định rằng các đối tượng phụ thuộc cũng sẽ bị xóa. Đây là một ví dụ về tham số XÓA có ý nghĩa, nhưng 'man rm' có thể cung cấp cho người khác. Làm thế nào những trường hợp này có thể được thực hiện trong REST / HTTP mà không có tham số?
2. @Jan, dường như đây là một quy ước được thiết lập tốt rằng phần đường dẫn của URL xác định một tài nguyên, trong khi chuỗi truy vấn thì không (ít nhất là không nhất thiết). Ví dụ rất nhiều: nhận cùng một tài nguyên nhưng ở định dạng khác, nhận các trường cụ thể của tài nguyên, v.v. Nếu chúng ta coi chuỗi truy vấn là một phần của mã định danh tài nguyên, không thể có khái niệm "các chế độ xem khác nhau của cùng một tài nguyên" mà không chuyển sang các cơ chế không RESTful như đàm phán nội dung HTTP (có thể không mong muốn vì nhiều lý do).

Ngoài câu trả lời của Alex:

Lưu ý rằng http: // server / resource / id? Force_delete = true xác định một tài nguyên khác với http: // server / resource / id . Ví dụ, đó là một sự khác biệt rất lớn cho dù bạn xóa / khách hàng /? Status = cũ hay / khách hàng /.

tháng một