การเชื่อมต่อกับแอปพลิเคชันเข้ากับข้อมูล
| English | ไทย |
|---|---|
| parameterised query/ˌpærəˈmetəraɪzd ˈkwɪərɪ/ | query แบบพารามิเตอร์ |
ID ที่ถูกต้องก็ยังสามารถขอข้อมูลส่วนตัวได้
- รหัสผู้เรียนอาจเป็นจำนวนเต็มที่ถูกต้องและยังอาจเป็นของผู้เรียนคนอื่นได้ การตรวจสอบอินพุตเพียงอย่างเดียวไม่ควรเปิดการเข้าถึงรายวิชาส่วนตัว
- สำหรับเส้นทางนี้ นักเรียนที่ผ่านการยืนยันตัวตนสามารถดูรายการของตนเองเท่านั้น ให้ระบุตัวตนของ callers และบังคับใช้นโยบายดังกล่าวก่อนดึงข้อมูลแถวส่วนตัว
รหัสนักเรียนที่ส่งมาอยู่ในประเภทที่ถูกต้อง แต่การค้นหาแบบส่วนตัวจำเป็นต้องตรวจสอบสิ่งใดเพิ่มเติม?
รูปแบบที่ถูกต้องไม่รับรองสิทธิ์ในการเข้าถึง
ดึงเฉพาะแถวและฟิลด์ที่ได้รับอนุญาต
- ** Query แบบพารามิเตอร์** จะผูกค่ารหัสผู้เรียนที่ได้รับอนุญาตเข้ากับข้อมูล เลือกเฉพาะฟิลด์ที่อินเทอร์เฟซต้องการ เช่น รหัสรายวิชาและชื่อ
- อย่าดาวน์โหลดบันทึกส่วนตัวสำหรับนักเรียนทุกคนแล้วซ่อนสิ่งที่ไม่ต้องการในเบราว์เซอร์ ผู้รับอาจตรวจสอบ response ได้ทั้งหมด
ทำไมบันทึกส่วนตัวของนักเรียนทุกคนจึงไม่ควรส่งไปและถูกซ่อนด้วยการกรองโดยเบราว์เซอร์เท่านั้น?
บังคับการเข้าถึงข้อมูลส่วนตัวบนเซิร์ฟเวอร์ก่อนส่งแถวกลับ
กำหนด response ว่างเปล่าและการปฏิเสธ
- ในสัญญาฉบับนี้ นักเรียนที่มีสิทธิ์แต่ไม่มีรายวิชาจะได้รับ 200 และ
[]ส่วนทรัพยากรที่ไม่มีอยู่หรือ callers ที่ถูกปฏิเสธจะเป็นไปตามนโยบาย API ที่ตกลงกันไว้ - นโยบายบางประเภทใช้ 404 เพื่อหลีกเลี่ยงการเปิดเผยการมีอยู่ส่วนตัว รักษาความสอดคล้องของนโยบายนี้; อย่าใช้ response ความสำเร็จเพื่อปกปิดความล้มเหลวของฐานข้อมูลที่คาดไม่ถึง
ภายใต้สัญญาเส้นทางนี้ มีนักเรียนที่ได้รับอนุญาตอยู่แต่ไม่มีรายวิชาใด Which response is appropriate?
รายการว่างที่สำเร็จเป็นผลลัพธ์ที่กำหนดไว้ ไม่ใช่ความล้มเหลวของฐานข้อมูล
แสดงผล response โดยไม่ให้สถานะสับสน
- เมื่อสำเร็จ ให้แสดงชื่อรายวิชาที่เลือกเป็นข้อความ แสดง “ยังไม่มีรายวิชา” เฉพาะเมื่อได้รับ response ว่างเปล่าที่สำเร็จแล้วเท่านั้น
- ระหว่างการโหลด ให้แสดงว่ากำลังรอ request处于pending状态。当失败时，解释列表无法加载并提供适当的重试选项；不要声称列表为空。
เขียนข้อความแยกต่างหากสำหรับกรณีรายการว่างสำเร็จ และกรณีคำขอล้มเหลว
"ยังไม่มีรายวิชา" แตกต่างจาก "ไม่สามารถโหลดรายวิชาได้ ลองอีกครั้ง"
จับคู่ความคืบหน้าของการตอบรับกับการแสดงผล
แสดงเฉพาะสิ่งที่ผลลัพธ์ที่สังเกตได้รองรับ
จัดการการเปลี่ยนแปลงโดยไม่กึ่งบันทึก
- การเขียนที่เกี่ยวข้องกับการเปลี่ยนแปลงหลายอย่างในฐานข้อมูลอาจต้องใช้ transaction: commit การเปลี่ยนแปลงตามเจตนารมณ์พร้อมกัน หรือ rollback เมื่อเกิดความล้มเหลว
- ตรวจสอบและอนุญาตการเขียนข้อมูลอย่างอิสระ การอ่านสำเร็จในครั้งก่อนหน้าไม่ได้อนุญาตให้มีการเปลี่ยนแปลงทั้งหมดในอนาคต หรือทำให้ค่าจากเมนูแบบเลื่อนลงปลอดภัยต่อการวางลงใน SQL
ค่าจากเมนูแบบrolling down ปลอดภัยสำหรับการวางลงใน SQL เนื่องจากผู้ใช้ไม่สามารถส่งค่าอื่นได้
ผู้เรียกสามารถส่งคำขอที่แก้ไขแล้วได้ ควรผูกค่าและตรวจสอบความถูกต้องบนเซิร์ฟเวอร์
การเขียนข้อมูลที่เกี่ยวข้องอาจต้องใช้ transaction เพื่อให้มั่นใจว่าหากเกิดข้อผิดพลาดจะไม่มีการบันทึกการเปลี่ยนแปลงเพียงบางส่วน
Transaction สามารถยืนยันหรือยกเลิกกลุ่มที่ต้องการได้ แต่ยังคงต้องมีการตรวจสอบและอนุมัติ权限
ทบทวนเส้นทางที่อนุญาตทั้งหมด
- ติดตามตัวตนและสิทธิ์ → ข้อมูลเข้าที่ยอมรับได้ → การค้นหาด้วยพารามิเตอร์ → คำตอบที่กำหนดไว้ → การแสดงผลที่ซื่อสัตย์ ทดสอบการปฏิเสธการเข้าถึงก่อนตรวจสอบการแสดงผล
- ใช้fixtures สำหรับรายการธรรมดา รายการว่าง และการร้องขอที่ล้มเหลว ยืนยันว่าฟิลด์ส่วนตัวและแถวของนักเรียนคนอื่นไม่ปรากฏในคำตอบที่ได้รับอนุญาต
คำสั่งที่ถูกต้องเป็นส่วนหนึ่งของเส้นทางที่ถูกต้อง ผู้เรียกใช้ ข้อมูลที่ได้รับ สัญญาการตอบรับ และสถานะที่มองเห็นได้ต้องสอดคล้องกัน
เรียงลำดับกระบวนการรายการรายวิชาที่ได้รับอนุญาตนี้
การตรวจสอบของเซิร์ฟเวอร์เกิดขึ้นก่อนการดึงและการจัดส่ง