REST, HTTP DELETE และพารามิเตอร์

มีอะไรที่ไม่เกี่ยวข้องกับการระบุพารามิเตอร์ให้กับคำขอ HTTP DELETE หรือไม่

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

วิธีแก้ปัญหาที่เรานำมาใช้คือการส่งพารามิเตอร์ไปยังคำขอลบเพื่อระบุว่าสามารถดำเนินการลบได้ ("? force_delete = true")

เช่น

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

ฉันเชื่อว่ามันยังคงผ่อนคลายตั้งแต่:

(a) ไม่มีการเปลี่ยนแปลงความหมายของ DELETE - ผู้ใช้ยังคงสามารถส่งคำขอ DELETE ตามปกติได้ แต่อาจล้มเหลวด้วย 409 และเนื้อหาของการตอบกลับจะอธิบายสาเหตุ ฉันบอกว่าอาจล้มเหลวเนื่องจาก (ด้วยเหตุผลที่ไม่คุ้มค่าที่จะอธิบาย) ในบางครั้งไม่มีเหตุผลที่จะแจ้งให้ผู้ใช้ทราบ

(b) ไม่มีอะไรในวิทยานิพนธ์ของ Roy ที่ชี้ให้เห็นว่ามันขัดต่อเจตนารมณ์ของ REST - ทำไมถึงเป็นเช่นนั้นเนื่องจาก HTTP เป็นเพียงการใช้งาน REST เพียงครั้งเดียวดังนั้นทำไมการส่งผ่านพารามิเตอร์ HTTP จึงมีความสำคัญ

ใครช่วยชี้ฉันด้วยคำพูดที่ชัดเจนว่าทำไมสิ่งนี้ถึงไม่สงบ?

ในคำถามที่เกี่ยวข้องหากผู้ใช้ไม่ได้ระบุ force_delete ฉันจะส่งคืน409 Conflict- รหัสตอบกลับที่เหมาะสมที่สุดหรือไม่

ติดตาม

หลังจากการวิจัยเพิ่มเติมฉันคิดว่าการเพิ่มพารามิเตอร์ใน DELETE อาจละเมิดหลักการหลายประการ

ประการแรกคือการใช้งานอาจละเมิด "Uniform Interface" (ดูหัวข้อ 5.1.5 ของวิทยานิพนธ์ของ Roy

ด้วยการเพิ่ม 'force_delete' เรากำลังเพิ่มข้อ จำกัด เพิ่มเติมในเมธอด DELETE ที่กำหนดไว้อย่างดี ข้อ จำกัด นี้มีความหมายสำหรับเราเท่านั้น

นอกจากนี้คุณยังสามารถโต้แย้งได้ว่าละเมิด "5.1.2 ไคลเอนต์ - เซิร์ฟเวอร์" เนื่องจากกล่องโต้ตอบการยืนยันเป็นปัญหาเกี่ยวกับ UI และลูกค้าบางรายอาจไม่ต้องการยืนยันการลบ

มีใครแนะนำไหม

ไม่มันไม่สงบ เหตุผลเดียวที่คุณควรใส่คำกริยา ( force_delete) ลงใน URI คือถ้าคุณต้องการโอเวอร์โหลดเมธอด GET / POST ในสภาพแวดล้อมที่ไม่มีเมธอด PUT / DELETE เมื่อพิจารณาจากการใช้เมธอด DELETE ของคุณไม่เป็นเช่นนั้น

409/Conflictควรใช้รหัสข้อผิดพลาด HTTP สำหรับสถานการณ์ที่มีข้อขัดแย้งซึ่งขัดขวางไม่ให้บริการ RESTful ดำเนินการ แต่ยังมีโอกาสที่ผู้ใช้อาจสามารถแก้ไขข้อขัดแย้งได้ด้วยตนเอง การยืนยันก่อนการลบ (ในกรณีที่ไม่มีความขัดแย้งที่แท้จริงซึ่งจะป้องกันการลบ) ไม่ใช่ข้อขัดแย้งใด ๆ เนื่องจากไม่มีสิ่งใดป้องกันไม่ให้ API ดำเนินการตามที่ร้องขอ

อย่างที่อเล็กซ์พูด (ฉันไม่รู้ว่าใครลงคะแนนเขาถูกต้อง) สิ่งนี้ควรได้รับการจัดการใน UI เนื่องจากบริการ RESTful ดังกล่าวเป็นเพียงการดำเนินการตามคำขอและควรเป็นแบบไร้สัญชาติ (กล่าวคือต้องไม่อาศัยการยืนยันโดยการถือ ข้อมูลฝั่งเซิร์ฟเวอร์ใด ๆ เกี่ยวกับคำขอ)

สองตัวอย่างวิธีการทำใน UI คือ:

• pre-HTML5 : * แสดงกล่องโต้ตอบการยืนยัน JS ให้กับผู้ใช้และส่งคำขอก็ต่อเมื่อผู้ใช้ยืนยัน
• HTML5 : * ใช้แบบฟอร์มที่มีการดำเนินการ DELETE โดยที่แบบฟอร์มจะมีเพียงปุ่ม "ยืนยัน" และ "ยกเลิก" ("ยืนยัน" จะเป็นปุ่มส่ง)

(*) โปรดทราบว่า HTML เวอร์ชันก่อนหน้า 5 ไม่รองรับเมธอด PUT และ DELETE โดยกำเนิด แต่เบราว์เซอร์สมัยใหม่ส่วนใหญ่สามารถใช้สองวิธีนี้ผ่านการเรียก AJAX ดูหัวข้อนี้สำหรับรายละเอียดเกี่ยวกับการรองรับข้ามเบราว์เซอร์

อัปเดต (ขึ้นอยู่กับการตรวจสอบและการอภิปรายเพิ่มเติม):

สถานการณ์ที่บริการต้องการให้มีการforce_delete=trueตั้งค่าสถานะละเมิดอินเตอร์เฟสที่เหมือนกันตามที่กำหนดไว้ในวิทยานิพนธ์ของ Roy Fielding นอกจากนี้ตามHTTP RFCเมธอด DELETE อาจถูกแทนที่บนเซิร์ฟเวอร์ต้นทาง (ไคลเอนต์) ซึ่งหมายความว่าสิ่งนี้ไม่ได้ทำบนเซิร์ฟเวอร์เป้าหมาย (บริการ)

ดังนั้นเมื่อบริการได้รับคำขอ DELETE ควรดำเนินการโดยไม่จำเป็นต้องมีการยืนยันเพิ่มเติม (ไม่ว่าบริการจะดำเนินการจริงหรือไม่ก็ตาม)

ฉันคิดว่านี่ไม่ใช่การพักผ่อน ฉันไม่คิดว่าบริการพักผ่อนควรจัดการกับข้อกำหนดในการบังคับให้ผู้ใช้ยืนยันการลบ ฉันจะจัดการสิ่งนี้ใน UI

การระบุ force_delete = true เหมาะสมหรือไม่หากเป็น API ของโปรแกรม หากมีคนเขียนสคริปต์เพื่อลบทรัพยากรนี้คุณต้องการบังคับให้ระบุ force_delete = true เพื่อลบทรัพยากรจริงหรือไม่

เป็นคำถามเก่า แต่นี่คือความคิดเห็นบางส่วน ...

1. ใน SQL คำสั่ง DELETE ยอมรับพารามิเตอร์ "CASCADE" ซึ่งอนุญาตให้คุณระบุว่าควรลบอ็อบเจ็กต์ที่เกี่ยวข้องด้วย นี่คือตัวอย่างของพารามิเตอร์ DELETE ที่สมเหตุสมผล แต่ 'man rm' สามารถให้ข้อมูลอื่น ๆ ได้ กรณีเหล่านี้จะนำไปใช้ใน REST / HTTP โดยไม่มีพารามิเตอร์ได้อย่างไร
2. @Jan ดูเหมือนว่าจะเป็นแบบแผนที่กำหนดไว้อย่างดีว่าส่วนของเส้นทางของ URL ระบุทรัพยากรในขณะที่สตริงการสืบค้นไม่ได้ (อย่างน้อยก็ไม่จำเป็น) ตัวอย่างมากมาย: การได้รับทรัพยากรเดียวกัน แต่อยู่ในรูปแบบที่แตกต่างกันการได้รับฟิลด์เฉพาะของทรัพยากร ฯลฯ หากเราพิจารณาสตริงการสืบค้นเป็นส่วนหนึ่งของตัวระบุทรัพยากรเป็นไปไม่ได้ที่จะมีแนวคิด "มุมมองที่แตกต่างกันของทรัพยากรเดียวกัน" โดยไม่หันไปใช้กลไกที่ไม่เป็นที่ต้องการเช่นการเจรจาต่อรองเนื้อหา HTTP (ซึ่งอาจไม่เป็นที่ต้องการด้วยเหตุผลหลายประการ)

นอกจากคำตอบของ Alex:

โปรดทราบว่าhttp: // server / ทรัพยากร / ID force_delete = trueระบุทรัพยากรที่แตกต่างจากhttp: // เซิร์ฟเวอร์ / ทรัพยากร / ID ตัวอย่างเช่นความแตกต่างอย่างมากไม่ว่าคุณจะลบ / ลูกค้า /? status = เก่าหรือ / ลูกค้า /

ม.ค.