บริบท

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

ดังนั้นการควบคุมภาวะพร้อมกันในแง่ร้ายไม่เหมาะสมเพราะจะต้องมีการจัดเก็บเซิร์ฟเวอร์ที่ลูกค้าจะได้รับการล็อคทรัพยากร การควบคุมภาวะพร้อมกันในแง่ดีนั้นจะถูกนำมาใช้ด้วยความช่วยเหลือของEtagส่วนหัว (btw ตามที่ฉันถาม/programming/30080634/concurrency-in-a-rest-api )

ปัญหา

ปัญหาหลักที่เกิดขึ้นกับกลไกการควบคุมภาวะพร้อมกันในแง่ดีคือคุณอนุญาตให้ลูกค้าทุกคนทำการดำเนินการใด ๆ ได้ตลอดเวลา

และฉันต้องการหลีกเลี่ยงสิ่งนั้นโดยไม่ทำลายหลักการไร้สัญชาติของ REST ฉันหมายความว่าลูกค้าทั้งหมดไม่สามารถดำเนินการใด ๆ ได้ตลอดเวลา

คำถาม

ในใจของฉันมันเป็นไปได้ด้วยกลไกการควบคุมภาวะพร้อมกันแบบกึ่งมองโลกในแง่ดีเช่นนั้น:

• ลูกค้าสามารถขอโทเค็น
• สามารถสร้างโทเค็นเดียวเท่านั้นและมีระยะเวลาที่ จำกัด
• หากต้องการดำเนินการกับทรัพยากร (เช่นPOSTหรือPUT ) ไคลเอ็นต์จะต้องให้โทเค็นนี้เป็นส่วนหนึ่งของเนื้อความ (หรือส่วนหัว?) ของคำขอ ลูกค้าที่ไม่มีโทเค็นไม่สามารถทำการดำเนินการเหล่านี้ได้

มันคล้ายกันมากกับการควบคุมภาวะพร้อมกันในแง่ดียกเว้นว่ามีลูกค้าเพียงรายเดียวเท่านั้นที่สามารถทำการดำเนินการบางอย่าง (ลูกค้าที่ได้รับโทเค็น) ... ตรงข้ามกับ "ลูกค้าทุกคนสามารถดำเนินการทั้งหมดได้"

กลไกนี้เข้ากันได้กับสไตล์สถาปัตยกรรม REST หรือไม่? มันทำลายข้อ จำกัด ใด ๆ หรือไม่? ฉันคิดว่าจะถาม SO แต่ดูเหมือนว่าจะเป็นคำถามระดับสูงที่เกี่ยวข้องกับการออกแบบซอฟต์แวร์

คุณไม่ควรล็อคทรัพยากรใด ๆ ในขณะที่รอการโต้ตอบจากผู้ใช้

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

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

คนส่วนใหญ่สามารถจัดการกับข้อความ "ขออภัยผู้ใช้รายอื่นเพิ่งสั่งส่วนนี้"

การใช้โทเค็นเป็นเรื่องธรรมดาใน API โทเค็นเหล่านี้มักจะส่งเป็นส่วนหัวและมีวงจรชีวิตที่ชัดเจน คิดเช่น OAuth

REST APIs ไม่ว่าภาษาหรือกรอบการเขียนโปรแกรมของคุณจะเป็นอย่างไร

ฉันสามารถนึกถึงหลาย ๆ สถานการณ์ที่คุณต้องการ จำกัด การทำงานพร้อมกันสองสถานการณ์คือ:

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

2. ผู้ใช้ขั้นสูงหรือผู้ดูแลระบบที่ดำเนินการพิเศษกับ API

จะทำอย่างไรในกรณีเหล่านี้?

1. ใช้ธุรกรรมในฐานข้อมูลซิงเกิลล็อคและกลไกที่คล้ายกันเพื่อซิงโครไนซ์การเข้าถึงทรัพยากร

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

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

เหลือเพียงอย่างเดียวดั้งเดิมเกินไปจริงๆ คุณสามารถเริ่มต้นด้วย REST แต่ในที่สุดแอปพลิเคชันที่สมบูรณ์ของคุณจะต้องใช้แบบสอบถามด้วยการเข้าร่วมและอัปเดตกับธุรกรรม นักพัฒนาซอฟต์แวร์ทุกคนที่พยายามเพิ่มสิ่งเหล่านี้ด้วยตนเองจะเกิดข้อผิดพลาดได้ง่ายและไม่สอดคล้องกัน โชคดีที่มีมาตรฐานใหม่ที่เรียกว่า OData ที่ทำเช่นนั้น มันอยู่ด้านบนของส่วนที่เหลือและให้ (1) ภาษาแบบสอบถามที่ช่วยให้การเข้าร่วมง่ายโดยใช้คุณสมบัติการนำทาง (โดยไม่ต้องเปิดเผยคีย์ต่างประเทศ) และ (2) การประมวลผลชุดที่มีชุดการเปลี่ยนแปลงอะตอม

ดูที่นี่สำหรับ (1) https://stackoverflow.com/a/3921423/471129และ

ดูที่นี่และ (2) https://stackoverflow.com/a/21939972/471129