การออกแบบ REST API สำหรับหน้าเว็บที่มีพ่อมด

ฉันมีหน้าเว็บที่มีรูปแบบตัวช่วยสร้าง ปุ่มส่งไปยัง API จะอยู่ในขั้นตอนที่ 4 ของตัวช่วยสร้าง อย่างไรก็ตามฉันต้องการให้ข้อมูลที่ป้อนถูกจัดเก็บในฐานข้อมูลก่อนที่จะย้ายไปยังขั้นตอนถัดไปในตัวช่วย ฉันต้องการให้ REST API ทำงานสำหรับหน้าเว็บที่มีแท็บเดียว

ดังนั้นฉันจึงออกแบบ API ให้ทำแบบสอบถามพารามิเตอร์ action = draft หรือส่ง หากการดำเนินการเป็นแบบร่างเฉพาะฟิลด์ที่บังคับเท่านั้น หากมีการส่งการกระทำฟิลด์ทั้งหมดจะถูกบังคับใช้ การตรวจสอบในชั้นบริการของ REST API จะดำเนินการตามพารามิเตอร์การสืบค้น ดูเหมือนว่าฉันจะระบุ if / else ในเอกสารอย่างชัดเจน นี่เป็นรูปแบบที่ยอมรับได้ของการออกแบบ RESTful หรือไม่ อะไรคือการออกแบบที่ดีที่สุดตามข้อกำหนดเหล่านี้

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

POST /wizard/123/step1
POST /wizard/123/step2
POST /wizard/123/step3

โดยการรวมลิงค์ไฮเปอร์มีเดียในการตอบสนองคุณสามารถแจ้งลูกค้าเกี่ยวกับสิ่งที่มันสามารถทำได้หลังจากขั้นตอนนี้ - ไปข้างหน้าหรือย้อนกลับสำหรับขั้นตอนตัวกลางและไม่มีอะไรสำหรับขั้นตอนสุดท้าย คุณสามารถดูตัวอย่างของมันในรูปที่ 5 ที่นี่

ฉันต้องทำสิ่งที่คล้ายกันเมื่อไม่นานมานี้และต่อไปนี้อธิบายสิ่งที่เราท้ายที่สุด

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

ข้อดีของวิธีการสองตาราง:

• ในฐานข้อมูลคุณสามารถมีข้อ จำกัด ที่เข้มงวดมากขึ้นในตารางรายการมากกว่าตาราง UnfinishedItem คุณไม่จำเป็นต้องมีคอลัมน์เสริมที่จำเป็นจริง ๆ เมื่อวิซาร์ดเสร็จสิ้น

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

ข้อเสีย:

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

ความเป็นไปได้อื่นที่ฉันได้พิจารณาและทำไมเราไม่ไปกับพวกเขา:

• การบันทึกข้อมูลในคุกกี้หรือที่เก็บข้อมูลในเครื่อง: ผู้ใช้ไม่สามารถดำเนินการส่งต่อจากอุปกรณ์อื่นหรือลบประวัติเบราว์เซอร์
• เก็บ UnfinishedItem เป็นข้อมูลที่ไม่มีโครงสร้าง (เช่น JSON) ในฐานข้อมูลหรือที่เก็บข้อมูลรอง: ฉันจะต้องกำหนดตรรกะการแยกวิเคราะห์และไม่สามารถใช้การตรวจสอบรูปแบบ / แบบฟอร์มอัตโนมัติของ Django ได้
• ทำการตรวจสอบตามขั้นตอนในฝั่งไคลเอ็นต์: ฉันจะต้องทำซ้ำตรรกะการตรวจสอบระหว่าง Python / Django และ JavaScript

ฉันนำสิ่งนี้ไปใช้ในลักษณะที่คล้ายคลึงกับโซลูชันของ @ guillauma31 และ @Lie Ryan

นี่คือแนวคิดที่สำคัญ:

1. มีวิซาร์ด 3 ขั้นตอนที่อาจคงอยู่เพียงบางส่วนจนกระทั่งเสร็จสมบูรณ์
2. แต่ละขั้นตอนมีทรัพยากรของตัวเอง (เช่น .: /users/:id_user/profile/step_1, .../step_2ฯลฯ )
3. ในแต่ละขั้นตอนข้อมูลและสถานะความสำเร็จสามารถดึงผ่านคำขอ GET และยืนยันผ่านคำขอ PATCH
4. แต่ละทรัพยากรมีกฎการตรวจสอบของตัวเองกับข้อมูลที่ป้อน
5. แต่ละขั้นตอนส่งคืนคีย์ที่ต้องใช้ในอินพุตของขั้นตอนถัดไปเพื่อรับประกันลำดับ เมื่อใช้หรือสร้างขึ้นใหม่โทเค็นนี้จะหมดอายุ
6. ในขั้นตอนสุดท้ายเรามีข้อมูลที่จำเป็นทั้งหมดในฐานข้อมูลและหน้าจอยืนยันจะปรากฏขึ้น ยืนยันนี้เรียกทรัพยากรอื่นที่จะทำเครื่องหมายข้อมูลเป็นฉบับสมบูรณ์ (เช่น .: .../profile/confirm) ทรัพยากรนี้ไม่จำเป็นต้องได้รับข้อมูลทั้งหมดอีกครั้ง มันเพียงทำเครื่องหมายข้อมูลว่าถูกต้องและครบถ้วน
7. มีรูทีนที่กำหนดเวลาไว้ซึ่งจะลบรายการที่ไม่สมบูรณ์ซึ่งมีเวลามากกว่าสองสามวัน

พวก front-end ต้องดูแลโทเค็นเพื่อให้โฟลว์ของตัวช่วยสร้างทำงานไปมา

API คือไร้สัญชาติและอะตอมมิก

ในการทำให้ "หนึ่งขั้นตัวช่วยสร้าง" ทำงานกับการตั้งค่านี้คุณจะต้องเปลี่ยนบางสิ่งเช่นลบโทเค็นโฟลว์หรือสร้างทรัพยากรเพื่อส่งกลับโทเค็นตามประเภทของตัวช่วยสร้างหรือแม้กระทั่งสร้างทรัพยากรใหม่เท่านั้น ตัวช่วยสร้างขั้นตอน (เช่นPUT /users/:id_user/profile/)