ทางเลือกอื่นที่น่าสนใจในการลบคำขอเนื้อหา

แม้ว่าข้อมูลจำเพาะ HTTP 1.1ดูเหมือนจะอนุญาตเนื้อหาข้อความในคำขอDELETEแต่ดูเหมือนว่าจะระบุว่าเซิร์ฟเวอร์ควรละเว้นเนื่องจากไม่มีความหมายที่กำหนดไว้

4.3 เนื้อหาข้อความ

เซิร์ฟเวอร์ควรอ่านและส่งต่อเนื้อหาข้อความตามคำขอใด ๆ หากวิธีการร้องขอไม่รวมความหมายที่กำหนดไว้สำหรับเอนทิตี - เนื้อความควรละเว้นเนื้อหาข้อความเมื่อจัดการกับคำขอ

ฉันได้ตรวจสอบการอภิปรายที่เกี่ยวข้องหลายหัวข้อเกี่ยวกับ SO และอื่น ๆ แล้วเช่น:

• อนุญาตให้ใช้เนื้อหาเอนทิตีสำหรับคำขอ HTTP DELETE หรือไม่
• เพย์โหลดของวิธีการขอ HTTP
• HTTP รับพร้อมเนื้อหาคำขอ

การอภิปรายส่วนใหญ่ดูเหมือนจะเห็นพ้องต้องกันว่าอาจอนุญาตให้มีเนื้อหาข้อความใน DELETE ได้แต่โดยทั่วไปไม่แนะนำ

นอกจากนี้ฉันสังเกตเห็นแนวโน้มในไลบรารีไคลเอ็นต์ HTTP ต่างๆซึ่งดูเหมือนว่าจะมีการบันทึกการปรับปรุงมากขึ้นเรื่อย ๆ สำหรับไลบรารีเหล่านี้เพื่อรองรับเนื้อหาคำขอใน DELETE ห้องสมุดส่วนใหญ่ดูเหมือนจะบังคับแม้ว่าบางครั้งจะมีการต่อต้านเล็กน้อย

กรณีการใช้งานของฉันเรียกร้องให้เพิ่มข้อมูลเมตาที่จำเป็นบางอย่างใน DELETE (เช่น "เหตุผล" ในการลบพร้อมกับข้อมูลเมตาอื่น ๆ ที่จำเป็นสำหรับการลบ) ฉันได้พิจารณาตัวเลือกต่อไปนี้ซึ่งไม่มีตัวเลือกใดที่เหมาะสมและสอดคล้องกับข้อกำหนด HTTP และ / หรือแนวทางปฏิบัติที่ดีที่สุดของ REST:

• Message Body - ข้อมูลจำเพาะระบุว่าเนื้อหาของข้อความบน DELETE ไม่มีค่าความหมาย ไคลเอ็นต์ HTTP ไม่ได้รับการสนับสนุนอย่างเต็มที่ ไม่ใช่แนวทางปฏิบัติมาตรฐาน
• ที่กำหนดเองส่วนหัว HTTP - การกำหนดส่วนหัวที่กำหนดเองโดยทั่วไปกับมาตรฐานการปฏิบัติ ; การใช้พวกเขาไม่สอดคล้องกับส่วนที่เหลือของ API ของฉันซึ่งไม่ต้องใช้ส่วนหัวที่กำหนดเอง ยิ่งไปกว่านั้นไม่มีการตอบสนอง HTTP ที่ดีเพื่อระบุค่าส่วนหัวที่กำหนดเองที่ไม่ถูกต้อง (อาจเป็นคำถามแยกกันทั้งหมด)
• ส่วนหัว HTTP มาตรฐาน - ไม่มีส่วนหัวมาตรฐานที่เหมาะสม
• พารามิเตอร์การสืบค้น - การเพิ่มพารามิเตอร์แบบสอบถามจะเปลี่ยนคำขอ -URI ที่ถูกลบไป การปฏิบัติตามมาตรฐาน
• วิธีการโพสต์ - (เช่นPOST /resourceToDelete { deletemetadata }) POST ไม่ใช่ตัวเลือกเชิงความหมายสำหรับการลบ POST แสดงถึงการกระทำตรงข้ามที่ต้องการ (เช่น POST สร้างผู้ใต้บังคับบัญชาทรัพยากร แต่ฉันต้องการลบทรัพยากร)
• วิธีการหลายวิธี - การแยกคำขอ DELETE ออกเป็นสองการดำเนินการ (เช่น PUT ลบข้อมูลเมตาจากนั้น DELETE) จะแยกการดำเนินการอะตอมออกเป็นสองส่วนซึ่งอาจทำให้สถานะไม่สอดคล้องกัน เหตุผลในการลบ (และข้อมูลเมตาอื่น ๆ ที่เกี่ยวข้อง) ไม่ได้เป็นส่วนหนึ่งของการแสดงทรัพยากรเอง

ความชอบอันดับแรกของฉันคือการใช้เนื้อหาข้อความรองจากส่วนหัว HTTP ที่กำหนดเอง อย่างไรก็ตามตามที่ระบุไว้มีข้อเสียบางประการสำหรับแนวทางเหล่านี้

มีคำแนะนำหรือแนวทางปฏิบัติที่ดีที่สุดที่สอดคล้องกับมาตรฐาน REST / HTTP สำหรับการรวมข้อมูลเมตาที่จำเป็นในคำขอ DELETE หรือไม่ มีทางเลือกอื่นที่ฉันไม่ได้พิจารณาหรือไม่?

แม้จะมีคำแนะนำบางประการที่จะไม่ใช้เนื้อหาข้อความสำหรับคำขอ DELETE แต่วิธีนี้อาจเหมาะสมในการใช้งานบางกรณี นี่เป็นแนวทางที่เราใช้หลังจากประเมินตัวเลือกอื่น ๆ ที่กล่าวถึงในคำถาม / คำตอบและหลังจากร่วมมือกับผู้บริโภคบริการ

แม้ว่าการใช้เนื้อหาข้อความจะไม่เหมาะ แต่ก็ไม่มีตัวเลือกอื่นใดที่เหมาะสมอย่างสมบูรณ์แบบเช่นกัน เนื้อหาคำขอ DELETE ช่วยให้เราเพิ่มความหมายรอบ ๆ ข้อมูล / ข้อมูลเมตาเพิ่มเติมที่จำเป็นในการดำเนินการ DELETE ได้อย่างง่ายดายและชัดเจน

ฉันยังคงเปิดกว้างสำหรับความคิดและการอภิปรายอื่น ๆ แต่ต้องการปิดการวนซ้ำของคำถามนี้ ฉันขอขอบคุณสำหรับความคิดและการอภิปรายของทุกคนในหัวข้อนี้!

สิ่งที่คุณต้องการคือหนึ่งในสองสิ่งซึ่งไม่ใช่สิ่งที่บริสุทธิ์DELETE:

1. คุณมีสองการดำเนินงานPUTในเหตุผลที่ลบตามมาด้วยDELETEของทรัพยากร เมื่อลบแล้วเนื้อหาของทรัพยากรจะไม่สามารถเข้าถึงได้โดยทุกคน 'เหตุผล' ไม่สามารถมีไฮเปอร์ลิงก์ไปยังทรัพยากรที่ถูกลบ หรือ,
2. คุณกำลังพยายามเปลี่ยนทรัพยากรจากเป็นstate=activeถึงstate=deletedโดยใช้DELETEเมธอด ทรัพยากรที่มี state = ลบจะถูกละเว้นโดย API หลักของคุณ แต่อาจยังอ่านได้สำหรับผู้ดูแลระบบหรือผู้ที่มีสิทธิ์เข้าถึงฐานข้อมูล อนุญาต - DELETEไม่จำเป็นต้องลบข้อมูลสำรองของทรัพยากรเพียงเพื่อลบทรัพยากรที่เปิดเผยใน URI นั้น

ดำเนินการใด ๆ ซึ่งจะต้องมีเนื้อหาของข้อความในDELETEคำขอสามารถถูกทำลายลงไปที่มันเป็นโดยทั่วไปส่วนใหญ่POSTจะทำทุกงานที่จำเป็นกับร่างกายข้อความ, DELETEและ ฉันไม่เห็นเหตุผลที่จะทำลายความหมายของ HTTP

จากสถานการณ์ที่คุณมีฉันจะใช้วิธีใดวิธีหนึ่งต่อไปนี้:

• ส่ง PUT หรือ PATCH : ฉันอนุมานได้ว่าการดำเนินการลบเป็นเสมือนโดยธรรมชาติของการต้องการเหตุผลในการลบ ดังนั้นฉันเชื่อว่าการอัปเดตระเบียนผ่านการดำเนินการ PUT / PATCH เป็นวิธีการที่ถูกต้องแม้ว่าจะไม่ใช่การดำเนินการ DELETE ต่อ se
• ใช้พารามิเตอร์การสืบค้น : ทรัพยากร uri ไม่ได้รับการเปลี่ยนแปลง ฉันคิดว่านี่เป็นแนวทางที่ถูกต้องเช่นกัน คำถามที่คุณเชื่อมโยงกำลังพูดถึงการไม่อนุญาตให้ลบหากพารามิเตอร์การค้นหาหายไป ในกรณีของคุณฉันจะมีเหตุผลเริ่มต้นถ้าเหตุผลนั้นไม่ได้ระบุไว้ในสตริงข้อความค้นหา resource/:idทรัพยากรที่จะยังคงอยู่ คุณสามารถทำให้ค้นพบได้ด้วยส่วนหัวของลิงก์ในทรัพยากรด้วยเหตุผลแต่ละข้อ (โดยมีrelแท็กที่แต่ละข้อเพื่อระบุเหตุผล)
• ใช้ปลายทางแยกต่างหากต่อเหตุผล : การใช้ URL resource/:id/canceledเช่น สิ่งนี้จะเปลี่ยน Request-URI จริง ๆ และไม่น่าสนใจอย่างแน่นอน อีกครั้งส่วนหัวของลิงก์สามารถทำให้ค้นพบได้

โปรดจำไว้ว่า REST ไม่ใช่กฎหมายหรือความเชื่อ คิดว่าเป็นแนวทางมากขึ้น ดังนั้นเมื่อเป็นเรื่องสมควรที่จะไม่ปฏิบัติตามคำแนะนำสำหรับโดเมนปัญหาของคุณอย่าทำ เพียงตรวจสอบให้แน่ใจว่าผู้บริโภค API ของคุณได้รับทราบถึงความแปรปรวน

ฉันขอแนะนำให้คุณรวมข้อมูลเมตาที่จำเป็นเป็นส่วนหนึ่งของลำดับชั้น URI เอง ตัวอย่าง (ไร้เดียงสา):

หากคุณต้องการลบรายการตามช่วงวันที่แทนที่จะส่งวันที่เริ่มต้นและวันที่สิ้นสุดในเนื้อความหรือเป็นพารามิเตอร์การค้นหาให้จัดโครงสร้าง URI ในลักษณะที่คุณส่งผ่านข้อมูลที่ต้องการเป็นส่วนหนึ่งของ URI

เช่น

DELETE /entries/range/01012012/31122012 - ลบรายการทั้งหมดระหว่างวันที่ 1 มกราคม 2555 ถึง 31 ธันวาคม 2555

หวังว่านี่จะช่วยได้