Tại sao không có phương pháp PUT và DELETE trên các biểu mẫu HTML?

HTML4 / XHTML1 chỉ cho phép GET và POST trong các biểu mẫu, bây giờ có vẻ như HTML5 sẽ làm điều tương tự. Có một đề xuất để thêm hai cái này nhưng nó dường như không đạt được lực kéo. Các lý do kỹ thuật hoặc chính trị cho việc không bao gồm PUT và DELETE trong dự thảo đặc tả HTML5 là gì?

Đây là một câu hỏi hấp dẫn. Các câu trả lời khác ở đây đều là suy đoán, và trong một số trường hợp không rõ ràng. Thay vì viết ý kiến ​​của tôi ở đây, tôi thực sự đã thực hiện một số nghiên cứu và tìm thấy các nguồn gốc thảo luận về lý do tại sao xóa và đặt không phải là một phần của tiêu chuẩn biểu mẫu HTML5.

Hóa ra, các phương thức này đã được bao gồm trong một số bản nháp HTML5 ban đầu (!), Nhưng sau đó đã bị xóa trong các bản nháp tiếp theo . Mozilla cũng đã thực sự thực hiện điều này trong bản beta Firefox .

Lý do để loại bỏ các phương pháp này khỏi dự thảo là gì? W3C đã thảo luận về chủ đề này trong báo cáo lỗi 10671 . Mike Amundsen lập luận ủng hộ sự hỗ trợ này:

Việc thực thi PUT và DELETE để sửa đổi tài nguyên trên máy chủ gốc là điều dễ dàng đối với các trình duyệt Web hiện đại sử dụng đối tượng XmlHttpRequest. Đối với các tương tác trình duyệt chưa được viết, điều này không đơn giản. [...]

Mẫu này được yêu cầu thường xuyên đến mức một số thư viện / khung Web thường được sử dụng đã tạo ra một công việc "tích hợp". [...]

Những ý kiến ​​khác:

• Sử dụng POST như một đường hầm thay vì sử dụng PUT / DELETE có thể dẫn đến bộ nhớ đệm mis-matches (ví dụ phản ứng POST là cachable , PUT phản ứng không (6), DELETE phản ứng không (7))
• Sử dụng phương pháp không tạm thời (POST) để thực hiện thao tác idempotent (PUT / DELETE) làm phức tạp quá trình phục hồi do lỗi mạng (ví dụ: "Có an toàn để lặp lại hành động này không?").
• [...]

Thật đáng để đọc toàn bộ bài viết của anh ấy.

Tom Wardrop cũng đưa ra một điểm thú vị:

HTML gắn bó chặt chẽ với HTTP. HTML là giao diện con người của HTTP. Do đó, nó tự động đặt câu hỏi tại sao HTML không hỗ trợ tất cả các phương thức có liên quan trong đặc tả HTTP. Tại sao máy móc có thể PUT và XÓA tài nguyên, nhưng con người không thể? [...]

Điều mâu thuẫn là mặc dù HTML có độ dài lớn để đảm bảo đánh dấu ngữ nghĩa, nhưng đến nay, không có nỗ lực nào để đảm bảo các yêu cầu HTTP ngữ nghĩa.

Lỗi cuối cùng đã được đóng lại khi W Do Fix của Ian Hickson sửa chữa , với lý do sau:

PUT như một phương thức biểu mẫu không có ý nghĩa, bạn sẽ không muốn PUT một tải trọng biểu mẫu. XÓA chỉ có ý nghĩa nếu không có tải trọng, vì vậy nó cũng không có ý nghĩa nhiều với các biểu mẫu.

Tuy nhiên, đó không phải là kết thúc của câu chuyện! Sự cố đã được đóng trong trình theo dõi lỗi W3C và chuyển sang trình theo dõi sự cố của Nhóm làm việc HTML:

https://www.w3.org/html/wg/tracker/issues/195

Tại thời điểm này, dường như lý do chính tại sao không có hỗ trợ cho các phương thức này chỉ đơn giản là không ai dành thời gian để viết một đặc tả toàn diện cho nó.

GET và POST có một lý do trung lập nội dung rõ ràng. GET là truy xuất nội dung của URL theo cách an toàn để lặp lại và có thể lưu vào bộ đệm. POST là làm một cái gì đó không an toàn để lặp lại, thực hiện theo suy đoán hoặc bộ đệm.

Không có lý do tương tự cho PUT hoặc DELETE. Cả hai đều được bao phủ hoàn toàn bởi POST. Tạo hoặc hủy tài nguyên là các hoạt động không an toàn để lặp lại, không an toàn để thực hiện theo suy đoán và không nên lưu vào bộ nhớ cache. Không có ngữ nghĩa đặc biệt bổ sung cần thiết cho họ.

Vì vậy, về cơ bản không có lợi ích.

Điều này đã được nêu ra vào năm 2010 khi Bug 10671 xem xét việc thêm hỗ trợ cho PUT và DELETE như các phương thức biểu mẫu .

Có một số lượng vừa phải cho "tính năng" này và một số sự nặng tay nhưng cuối cùng điều này đã được leo thang vì hai vấn đề trên trình theo dõi lỗi của Nhóm làm việc:

• ISSUE-195: Tăng cường tạo yêu cầu http từ các biểu mẫu
• ISSUE-196: Xác định hành vi xử lý phản hồi http của tác nhân người dùng

Vấn đề ISSUE-196 dẫn đến quyết định đồng thuận không thực hiện thay đổi nào đối với thông số kỹ thuật vì đặc tả HTML hiện không giới hạn cách xử lý các phản hồi đối với các yêu cầu POST. Tôi tin rằng vấn đề cụ thể này đã được nêu ra khi cố gắng điều hòa các mẫu chuyển hướng POST thường được sử dụng và cách các máy chủ ReSTful thường cung cấp phản hồi 2xx với các tin nhắn ngắn thay vì thứ gì đó hữu ích được hiển thị trong trình duyệt.

Vấn đề ISSUE-195 đã được trình bày trên ghế. Cameron Jones đã tăng cường tình nguyện viết một đề xuất thay đổi vào ngày 18 tháng 1 năm 2012 mà anh đã đệ trình để trở thành dự thảo làm việc đầu tiên vào ngày 29 tháng 5 năm 2014. Dự thảo sẽ thông qua quy trình khuyến nghị của W3C .

Với bất kỳ may mắn nào, điều này sẽ sớm trở thành khuyến nghị của W3C và được các nhà cung cấp trình duyệt triển khai và sẽ là một bước tiến lớn trong việc loại bỏ các trình chặn để tạo ra các dịch vụ ReSTful hợp nhất, có ngữ nghĩa và trình duyệt. Tôi tưởng tượng điều này sẽ châm ngòi cho một sự phát triển thú vị trong các mẫu dịch vụ. Có một bài nói hay của Jon Moore - API Hypermedia đáng xem, điều này khiến tôi thích thú nhưng đã ngã xuống ở rào cản đầu tiên (cái này).

Tôi hiểu rằng các trình duyệt không biết phải làm gì sau khi họ gửi PUT hoặc XÓA. POST sẽ thường chuyển hướng đến một trang thích hợp, nhưng PUT và DELETE thường không. Điều này làm cho chúng thích hợp để gọi qua ajax hoặc chương trình gốc, nhưng không phải từ một mẫu trình duyệt web.

Tôi không thể cản trở nó ngay bây giờ, nhưng tôi nhớ đã đọc một trong những danh sách gửi thư html5 khi họ đang thảo luận về điều này.

Lịch sử

Tôi nghĩ rằng đáng để đề cập đến sự xuất hiện đầu tiên của các hình thức html trong RFC1866 (Phần 8.1) . Ở đây thuộc tính phương thức được định nghĩa như sau:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Giải thích thêm được đặt trong Mục 8.2.2 - NHẬN và Phần 8.2.3 - POST

Hãy nhớ rằng HTML 2.0 (tháng 11 năm 1995) đã được chỉ định trước HTTP 1.0 (tháng 5 năm 1996). Vì vậy, mọi người chỉ sử dụng HTTP với GET (kể từ HTTP 0.9) hoặc với phần mở rộng POST. Nhưng chỉ có một vài máy chủ web hỗ trợ PUT và DELETE (như đã nêu trong Phụ lục HTTP 1.0 ).

Suy nghĩ

Nếu bạn nghĩ về cách phát triển web ngữ nghĩa của Berners-Lee có thể phát triển thì có vẻ như rõ ràng rằng nó đã đi từ các vấn đề thực tế đến một khái niệm chung. Đầu tiên anh muốn chia sẻ tài liệu. Vì vậy, ông cần đánh dấu. Sau đó, anh ta muốn truy vấn cơ sở dữ liệu cho nội dung, vì vậy anh ta cần các hình thức. Sau đó, anh muốn đưa dữ liệu mới vào cơ sở dữ liệu. Vì vậy, ông đã sử dụng các hình thức với GET và POST. Sau đó, anh ta có thể nhận ra rằng bạn có thể thực hiện mọi thao tác CRUD trên dữ liệu từ xa, vì vậy HTTP được mở rộng nhưng không bao giờ HTML vì quá muộn (chỉ một số máy chủ hỗ trợ các hoạt động CRUD mới).

Chỉ cần đưa ra một phỏng đoán hoang dã, nhưng có lẽ vì HTTP không tốt lắm với việc kiểm soát truy cập vào thời điểm tốt nhất và điều cuối cùng mà mọi người cần là nhiều cách hơn nữa để các URL độc hại xâm phạm một trang web và / hoặc ứng dụng được bảo mật kém.

HTTP thực sự không phải là một giao thức tốt để chuyển tập tin ngoài việc tải xuống từ máy chủ đến máy khách. Sử dụng FTP - hoặc tốt hơn nữa, SFTP.

Nhận và đăng là các định dạng truyền dữ liệu của yêu cầu.

Tôi cho rằng bạn đang hỏi về việc gửi biểu mẫu vào dịch vụ RESTFUL. Nhưng sẽ không có ý nghĩa khi thay đổi tiêu chuẩn yêu cầu http để đưa ra các giả định về mục đích của yêu cầu http. Thông tin về mục đích điền yêu cầu được xử lý tốt nhất trong các trường đầu vào.

Có một địa chỉ và nhận và đăng bài cho phép máy chủ diễn giải yêu cầu và giá trị đầu vào của nó một cách chính xác. Từ đó, các giá trị đầu vào cho phép bạn thực hiện các yêu cầu kết thúc mở đến máy chủ và thực hiện những gì bạn muốn. Ví dụ: bạn có thể có một trường có các giá trị là "đặt" và "xóa"