ทำไมไม่มีวิธี PUT และ DELETE ในแบบฟอร์ม HTML?

HTML4 / XHTML1 อนุญาตเฉพาะ GET และ POST ในรูปแบบตอนนี้ดูเหมือนว่า HTML5 จะทำเช่นเดียวกัน มีข้อเสนอให้เพิ่มสองสิ่งนี้ แต่ดูเหมือนจะไม่ดึงดูดความสนใจ อะไรคือเหตุผลทางเทคนิคหรือทางการเมืองสำหรับการไม่รวม PUT และ DELETE ในร่างข้อกำหนด HTML5

นี่เป็นคำถามที่น่าสนใจ คำตอบอื่น ๆ ที่นี่ล้วนเป็นการเก็งกำไรและในบางกรณีการถอนออกไม่ถูกต้อง แทนที่จะเขียนความคิดเห็นของฉันที่นี่ฉันได้ทำการวิจัยและพบแหล่งต้นฉบับที่กล่าวถึงสาเหตุที่ลบและวางไม่ได้เป็นส่วนหนึ่งของมาตรฐานฟอร์ม HTML5

ตามที่ปรากฎวิธีการเหล่านี้จะรวมอยู่ในร่าง HTML5 ช่วงต้น (!) หลายต้นแต่ถูกลบออกในภายหลังในร่างถัดไป Mozilla ได้นำสิ่งนี้ไปใช้ใน Firefox เบต้าด้วยเช่นกัน

เหตุผลในการลบวิธีการเหล่านี้ออกจากร่างคืออะไร ของ W3C กล่าวถึงหัวข้อนี้ในรายงานข้อบกพร่อง 10671 Mike Amundsen แย้งกับการสนับสนุนนี้:

การดำเนินการ PUT และ DELETE เพื่อแก้ไขทรัพยากรบนเซิร์ฟเวอร์ต้นทางนั้นตรงไปข้างหน้าสำหรับเว็บเบราว์เซอร์ที่ทันสมัยโดยใช้วัตถุ XmlHttpRequest สำหรับการโต้ตอบกับเบราว์เซอร์ที่ไม่ได้กำหนดสิ่งนี้ไม่ง่ายเลย [ ... ]

รูปแบบนี้จำเป็นต้องใช้บ่อยครั้งที่เว็บเฟรมเวิร์ก / ไลบรารีที่ใช้กันทั่วไปหลายรายการได้สร้างการทำงานแบบ "มีอยู่" ภายใน [ ... ]

ข้อควรพิจารณาอื่น ๆ :

• การใช้โพสต์เป็นอุโมงค์แทนการใช้ใส่ / ลบสามารถนำไปสู่การแคชผิดพลาดการแข่งขัน (เช่นการตอบสนอง POST มีcachableใส่การตอบสนองไม่ได้ (6), ลบการตอบกลับไม่ได้ (7))
• การใช้วิธีที่ไม่ใช่ idempotent (POST) เพื่อดำเนินการ idempotent (PUT / DELETE) ทำให้การกู้คืนมีความซับซ้อนเนื่องจากความล้มเหลวของเครือข่าย (เช่น "ปลอดภัยต่อการทำซ้ำการกระทำนี้หรือไม่")
• [ ... ]

มันคุ้มค่าที่จะอ่านโพสต์ทั้งหมดของเขา

Tom Wardrop ทำให้ประเด็นที่น่าสนใจ:

HTML ถูกผูกมัดกับ HTTP อย่างแยกไม่ออก HTML เป็นส่วนต่อประสานกับมนุษย์ของ HTTP ดังนั้นจึงเป็นเรื่องที่น่าสงสัยโดยอัตโนมัติว่าทำไม HTML ไม่สนับสนุนวิธีการที่เกี่ยวข้องทั้งหมดในข้อมูลจำเพาะ HTTP เหตุใดเครื่องจักรจึงสามารถใส่ทรัพยากร PUT และ DELETE แต่มนุษย์ไม่สามารถทำได้ [ ... ]

เป็นเรื่องที่ขัดแย้งกันว่าในขณะที่ HTML มีความยาวมากเพื่อให้แน่ใจว่ามาร์กเกอร์เชิงความหมายจะต้องมีความพยายามในการรับรองคำขอ HTTP ความหมาย

ในที่สุดข้อผิดพลาดก็ถูกปิดในที่สุดเนื่องจากจะไม่แก้ไขโดย Ian Hickson โดยมีเหตุผลดังต่อไปนี้:

ใส่ PUT เป็นวิธีการแบบไม่มีเหตุผลคุณไม่ต้องการใส่แบบฟอร์ม payload ลบเหมาะสมเท่านั้นหากไม่มีน้ำหนักบรรทุกดังนั้นจึงไม่สมเหตุสมผลกับรูปแบบเช่นกัน

อย่างไรก็ตามนั่นไม่ใช่จุดจบของเรื่องราว! ปัญหาที่ถูกปิดในบั๊ก W3C และเพิ่มขึ้นไป HTML คณะทำงานติดตามปัญหา:

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

ณ จุดนี้ดูเหมือนว่าเหตุผลหลักที่ว่าทำไมไม่มีการสนับสนุนสำหรับวิธีการเหล่านี้ก็คือว่าไม่มีใครได้ใช้เวลาในการเขียนข้อกำหนดที่ครอบคลุมสำหรับมัน

GET และ POST มีเหตุผลที่ชัดเจนสำหรับเนื้อหาที่เป็นกลาง GET คือการดึงเนื้อหาของ URL ด้วยวิธีที่ปลอดภัยในการทำซ้ำและอาจเป็นแคช โพสต์คือการทำบางสิ่งบางอย่างในลักษณะที่ไม่ปลอดภัยที่จะทำซ้ำดำเนินการ speculatively หรือแคช

ไม่มีเหตุผลที่คล้ายคลึงกันสำหรับ PUT หรือ DELETE พวกเขาทั้งสองได้รับการคุ้มครองอย่างสมบูรณ์โดย POST การสร้างหรือการทำลายทรัพยากรเป็นการดำเนินการที่ไม่ปลอดภัยในการทำซ้ำไม่ปลอดภัยในการดำเนินการโดยเฉพาะและไม่ควรถูกแคช ไม่มีความหมายพิเศษเพิ่มเติมที่จำเป็นสำหรับพวกเขา

ดังนั้นโดยทั่วไปไม่มีประโยชน์

นี้จะถูกยกขึ้นในปี 2010 เป็น10,671 Bug พิจารณาเพิ่มการสนับสนุนสำหรับ PUT และลบเป็นวิธีการรูปแบบ

มีจำนวนการกดย้อนกลับปานกลางสำหรับ "ฟีเจอร์" นี้และการใช้งานหนัก แต่ในที่สุดก็เพิ่มเป็นปัญหาสองประการในตัวติดตามบั๊ก Working Group:

• ปัญหา -195: ปรับปรุงการสร้างคำขอ http จากแบบฟอร์ม
• ISSUE-196: กำหนดพฤติกรรมการจัดการการตอบสนองต่อ http ของตัวแทนผู้ใช้

ปัญหาISSUE-196ส่งผลให้มีการตัดสินใจร่วมกันเพื่อทำการเปลี่ยนแปลงข้อกำหนดในขณะที่ข้อกำหนด HTML ไม่ได้ จำกัด วิธีการจัดการการตอบสนองต่อการร้องขอ POST ฉันเชื่อว่าปัญหานี้เกิดขึ้นจากการพยายามปรับรูปแบบการเปลี่ยนเส้นทาง POST ที่ใช้บ่อยและเซิร์ฟเวอร์ ReSTful มักให้การตอบกลับ 2xx พร้อมข้อความสั้นมากกว่าสิ่งที่มีประโยชน์ในการแสดงผลในเบราว์เซอร์

ปัญหาISSUE-195ถูกนำเสนอต่อเก้าอี้ คาเมรอนโจนส์ก้าวขึ้นไปเป็นอาสาสมัครในการเขียนข้อเสนอการเปลี่ยนแปลงใน 18 มกราคม 2012 ที่เขาส่งมาจะกลายเป็นร่างการทำงานครั้งแรกใน 29 พฤษภาคม 2014 ร่างจะไปผ่านกระบวนการคำแนะนำ W3C

ด้วยโชคใด ๆ สิ่งนี้จะกลายเป็นคำแนะนำของ W3C และนำไปใช้โดยผู้จำหน่ายเบราว์เซอร์และจะเป็นขั้นตอนต่อไปที่ยอดเยี่ยมในการลบตัวบล็อกเพื่อให้บริการ ReSTful ที่เป็นมิตรความหมายและเป็นมิตรกับเบราว์เซอร์ ฉันคิดว่านี่จะจุดประกายการวิวัฒนาการที่น่าสนใจในรูปแบบการบริการ มีการพูดคุยที่ดีจากJon Moore - การรับชม Hypermedia API ที่คุ้มค่านี่เป็นสิ่งที่ฉันสนใจ แต่ก็ล้มลงในอุปสรรคแรก (อันนี้)

ความเข้าใจของฉันคือเบราว์เซอร์ไม่ทราบว่าต้องทำอย่างไรเมื่อพวกเขาส่ง PUT หรือ DELETE โดยปกติแล้ว POST จะเปลี่ยนเส้นทางไปยังหน้าที่เหมาะสม แต่โดยทั่วไปแล้ว PUT และ DELETE จะไม่ทำเช่นนั้น สิ่งนี้ทำให้พวกเขาเหมาะสมสำหรับการโทรผ่าน ajax หรือโปรแกรมเนทีฟ แต่ไม่ใช่จากเว็บเบราว์เซอร์

ฉันไม่สามารถขัดขวางได้ในตอนนี้ แต่ฉันจำได้ว่าอ่านรายการส่งเมล html5 หนึ่งรายการเมื่อพวกเขาพูดคุยเรื่องนี้

ประวัติศาสตร์

ฉันคิดว่ามันเป็นมูลค่าการกล่าวขวัญปรากฏตัวครั้งแรกในรูปแบบ HTML ในRFC1866 (มาตรา 8.1) ที่นี่แอตทริบิวต์วิธีการที่ถูกกำหนดไว้ดังต่อไปนี้:

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".

คำอธิบายเพิ่มเติมอยู่ในหัวข้อ 8.2.2 - GETและมาตรา 8.2.3 - POST

โปรดทราบว่า HTML 2.0 (พ.ย. 1995) ถูกระบุไว้ก่อน HTTP 1.0 (พฤษภาคม 1996) ดังนั้นทุกคนจึงใช้ HTTP กับ GET เท่านั้น (ตั้งแต่ HTTP 0.9) หรือด้วยส่วนขยาย POST แต่มีเว็บเซิร์ฟเวอร์เพียงไม่กี่ตัวที่รองรับ PUT และ DELETE (เช่นที่ระบุในHTTP 1.0 Appendix )

ความคิด

หากคุณคิดว่าการพัฒนาเว็บเชิงความหมายของ Berners-Lee จะมีวิวัฒนาการมาได้อย่างไรมันก็ชัดเจนว่ามันเกิดจากปัญหาที่แท้จริงไปสู่แนวคิดทั่วไป ก่อนอื่นเขาต้องการแบ่งปันเอกสาร ดังนั้นเขาต้องการมาร์กอัป จากนั้นเขาต้องการสืบค้นฐานข้อมูลสำหรับเนื้อหาดังนั้นเขาจึงต้องการฟอร์ม จากนั้นเขาต้องการที่จะนำข้อมูลใหม่เข้าสู่ฐานข้อมูล ดังนั้นเขาจึงใช้แบบฟอร์มกับ GET และ POST หลังจากนั้นเขาอาจรู้ว่าคุณสามารถดำเนินการ CRUD ทุกครั้งกับข้อมูลจากระยะไกลได้ดังนั้น HTTP จึงถูกขยาย แต่ไม่ใช้ HTML เพราะมันสายเกินไป

เพียงแค่การขว้างปาออกเดาป่า แต่อาจจะเป็นเพราะไม่ได้เป็น HTTP ชะมัดดีกับการควบคุมการเข้าถึงที่ดีที่สุดของครั้งและสิ่งสุดท้ายที่ทุกคนต้องการที่จะยิ่งมากขึ้นวิธีสำหรับ URL ที่เป็นอันตรายที่จะประนีประนอมเว็บไซต์ที่มีความปลอดภัยไม่ดีและ / หรือแอพลิเคชัน

HTTP ไม่ใช่โปรโตคอลที่ดีสำหรับการถ่ายโอนไฟล์นอกเหนือจากการดาวน์โหลดจากเซิร์ฟเวอร์ไปยังไคลเอนต์ ใช้ FTP - หรือดีกว่า SFTP

รับและโพสต์เป็นรูปแบบของการส่งข้อมูลของคำขอ

ฉันคิดว่าคุณกำลังขอให้ส่งแบบฟอร์มลงในบริการ RESTFUL แต่มันก็ไม่สมเหตุสมผลที่จะเปลี่ยนมาตรฐานการร้องขอ http เพื่อให้ข้อสันนิษฐานวัตถุประสงค์ของการร้องขอ http ข้อมูลเกี่ยวกับวัตถุประสงค์ที่คำขอเติมได้รับการจัดการที่ดีที่สุดในฟิลด์อินพุต

มีที่อยู่และรับและโพสต์ช่วยให้เซิร์ฟเวอร์ตีความคำขอและเป็นค่าอินพุตที่ถูกต้อง จากนั้นค่าอินพุตจะอนุญาตให้คุณสร้างคำร้องขอสิ้นสุดที่เปิดไปยังเซิร์ฟเวอร์และทำสิ่งที่คุณต้องการ ตัวอย่างเช่นคุณสามารถมีฟิลด์ที่มีค่าเป็น "put" และ "delete"