ฉันจะออกแบบทรัพยากรรายการที่สั่งซื้อในบริการที่สงบได้อย่างไร

ฉันพบปัญหาเดียวกันนี้ซ้ำแล้วซ้ำอีกและฉันไม่พบวิธีแก้ปัญหาที่ฉันรู้สึกว่าเหมาะสมที่สุด

พูดในแอปคุณมีรายการที่สั่งซื้อและคุณให้ผู้ใช้เปลี่ยนลำดับนั้นโดยการลากและวางหรือบางอย่าง คุณต้องการให้การเปลี่ยนแปลงนั้นยังคงอยู่ คุณทำแบบนั้นอย่างไร

ฉันจะออกแบบบริการพักผ่อนของทรัพยากรรายการที่สั่งซื้อได้อย่างไร

โดยเฉพาะอย่างยิ่งฉันจะออกแบบlistและitemรูปแบบของทรัพยากรที่สงบได้อย่างไร การออกแบบที่พบบ่อยที่สุดที่ฉันเคยเห็นคือitemเอนทิตีที่มีorderหรือpositionคุณสมบัติ อีกวิธีที่ฉันได้ยินคือรายการที่เชื่อมโยงเป็นสองเท่าในรายการ

อะไรคือวิธีการที่ไม่เขียนฐานข้อมูลมากเกินไปและโดยทั่วไปแล้วรวดเร็วในการอัพเดตและอ่านสำหรับลูกค้า? จุดสิ้นสุดควรถูกเปิดเผยอย่างไร

การแสดงรายการที่เรียงลำดับเป็นหนึ่งในปัญหาที่ยากกับฐานข้อมูลเชิงสัมพันธ์ การเพิ่มคุณสมบัติตำแหน่งให้กับความสัมพันธ์แบบสมาชิก - ลิสต์เป็นวิธีที่พบได้บ่อยที่สุดเนื่องจากคุณสามารถดึงข้อมูลรายการที่สั่งซื้อได้อย่างง่ายดายโดยการเพิ่มORDER BY positionลงในคิวรี SQL ของคุณและเพราะคุณสามารถแทรกรายการในรายการได้โดยง่าย ค่าของสมาชิกรายการก่อนหน้าและถัดไปโดยสมมติว่าตำแหน่งเป็นทศนิยมมากกว่าจำนวนเต็ม

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

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

หากคุณมีองค์ประกอบเพียงไม่กี่ร้อยรายการในรายการเพียงโอนรายการทั้งหมดในคำขอ สมมติว่าเราต้องการจัดลำดับใหม่[1, 2, 3, 4]ที่สมาชิกรายการเป็น ID เราสามารถทำได้

POST /url/of/the/list
Content-type: application/json
...

[1, 2, 4, 3]

ส่วนหลังอาจแปลสิ่งนี้เป็นเทคโนโลยีฐานข้อมูลใด ๆ ก็ตามที่คุณใช้ แต่ผู้ใช้ API ไม่ต้องพิจารณารายละเอียดเหล่านี้

หากรายการมีขนาดใหญ่และรายการมักจะถูกขอเป็นรายบุคคลคุณสามารถอนุญาตให้ดัชนีใน URL:

GET /page/7

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

ถ้ารายการมีขนาดใหญ่มากคุณอาจต้องการที่จะเปิดเผยArrayListเหมือนการดำเนินการเช่นinsertหรือ/push appendฉันนึกภาพการโทรออกเช่น

POST /url/of/the/list?at=1357;mode=insert
...

description of the item to insert

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

POST /url/of/the/list/reorder-item?from=783;to=1357

หากรายการที่จัดลำดับใหม่ควรถูกกำหนดอย่างชัดเจนจะง่ายกว่าที่จะโอนคำสั่งซื้อใหม่เป็นเอกสาร JSON ดูด้านบน

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

ฉันคิดว่าศักยภาพของวิธีการที่แตกต่างกันขึ้นอยู่กับฐานข้อมูลที่ใช้

วิธีการนี้แนะนำให้ย้ายรายการในการสั่งซื้อ:

POST / url / of / the / list / reorder-item? from = 783; ถึง = 1357

ที่สามารถอยู่ภายใต้เงื่อนไขการแข่งขันเว้นแต่ว่าคุณจะมีความสามารถในการทำธุรกรรมได้ ระดับเริ่มต้นของ READ_COMMITTED ในฐานข้อมูลส่วนใหญ่จะไม่กำจัดเงื่อนไขการแข่งขัน!

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

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