Front end และ back end
| English | ไทย |
|---|---|
| request/rɪˈkwest/ | ขอ |
| front end/frʌnt end/ | ส่วนหน้า |
| back end/bæk end/ | ส่วนหลัง |
| server/ˈsɜːvə/ | เซิร์ฟเวอร์ |
| response/rɪˈspɒns/ | การตอบสนอง |
| API/ˌeɪ piː ˈaɪ/ | API |
| JSON/ˈdʒeɪsn/ | JSON |
ผู้เรียนเปลี่ยนตัวเลขใน URL
- หน้าคอร์สขอ
/students/42/coursesผู้เยี่ยมชมเปลี่ยน 42 เป็น 43 การซ่อนลิงก์นั้นบนหน้าจอไม่阻止การขอข้อมูลนี้ - ส่วนหน้า (Front end) แสดงอินเทอร์เฟซ ส่วนหลัง (Back end) ทำงานบน เซิร์ฟเวอร์ และประมวลผล คำร้อง ก่อนส่ง คำตอบ
agreement ความหมายของแต่ละคำร้อง
- API กำหนดวิธีการสื่อสารของซอฟต์แวร์ สัญญาจะระบุวิธี (method), เส้นทาง (path), ข้อมูลเข้า, ผู้เรียกที่ได้รับอนุญาต,-fields ของคำตอบ และพฤติกรรมเมื่อล้มเหลว
- สำหรับรายการ kursusสำหรับนักเรียนเท่านั้น เซิร์ฟเวอร์ต้องระบุตัวตนผู้เรียกและตรวจสอบสิทธิ์ จำนวนที่เบราว์เซอร์ส่งมาไม่ใช่หลักฐานยืนยันตัวตน
เบราว์เซอร์ขอรายการ 43 ของนักเรียน สิ่งใดพิสูจน์ได้ว่าผู้เรียกอาจอ่านรายการนี้ได้?
ID ใช้เลือกทรัพยากร; ไม่ใช่หลักฐานยืนยันตัวตนหรือสิทธิ์ในการเข้าถึง
อ่านคำตอบในฐานะข้อมูล
- JSON สามารถแทนค่าวัตถุ (objects),数组 (arrays), string, numbers, booleans และ null ได้ เป็นรูปแบบทั่วไปใน API บนเว็บ แต่ไม่ใช่ทุกคำตอบจะใช้รูปแบบนี้
- รายการสำเร็จอาจเป็น
[{"course_id":7,"title":"Robotics"}]รายการที่อนุญาตแต่ว่างเปล่าอาจเป็น[]; Neither result บังคับให้เบราว์เซอร์รันโค้ด
รูปแบบข้อมูลทั่วไปใดที่แสดงโดย [{"course_id":7,"title":"Robotics"}]?
นี่คือ JSON: อาร์เรย์ที่มีออบเจกต์อยู่ภายใน
วางกฎแต่ละข้อในที่ที่บังคับใช้ได้
- การตรวจสอบด้วยเบราว์เซอร์ให้ผลลัพธ์รวดเร็ว แต่เซิร์ฟเวอร์ต้องตรวจสอบข้อมูลเข้าและสิทธิ์อย่างอิสระ ผู้เรียกสามารถส่งคำร้องได้โดยไม่ต้องใช้ฟอร์มของคุณ
- เก็บรหัสผ่านฐานข้อมูลและกุญแจ API ส่วนตัวไว้บนเซิร์ฟเวอร์ ผู้ใช้อาจพิมพ์รหัสผ่านเข้าสู่ระบบลงในเบราว์เซอร์; ส่งผ่าน它以ปลอดภัยและไม่ฝังกุญแจบริการส่วนตัวในโค้ดที่ดาวน์โหลดได้
รหัสผ่านฐานข้อมูลส่วนตัวที่ใช้โดยแอปพลิเคชันควรเก็บไว้ที่ใด?
โค้ดที่ดาวน์โหลดได้สามารถตรวจสอบได้ ควรเก็บ凭据บริการส่วนตัวไว้บนเซิร์ฟเวอร์เท่านั้น
เซิร์ฟเวอร์จำเป็นต้องตรวจสอบข้อมูลเข้าอย่างอิสระ แม้ว่าจะมีแบบฟอร์มที่ตรวจสอบข้อมูลแล้วก็ตาม
ผู้เรียกสามารถข้ามแบบฟอร์มและส่งคำขอโดยตรงได้
อธิบายว่าทำไมการตรวจสอบจากเบราว์เซอร์จึงไม่สามารถแทนที่การตรวจสอบบนเซิร์ฟเวอร์ได้
ผู้เรียกสามารถส่งคำขอโดยไม่ผ่านแบบฟอร์ม ดังนั้นเซิร์ฟเวอร์จึงต้องตรวจสอบอย่างอิสระ
แสดงสถานะโหลด ความสำเร็จ และความล้มเหลวอย่างตรงไปตรงมา
- ขณะคำร้องกำลังดำเนินการ ให้แสดงสถานะโหลด หลังสำเร็จ ให้แสดง kursusที่รับกลับหรือข้อความรายการว่าง
- คำขอที่ล้มเหลวจำเป็นต้องมีสถานะความล้มเหลวที่มีประโยชน์ อย่าระบุความล้มเหลวของเครือข่ายว่าเป็น "ไม่มีรายวิชา" เนื่องจากเซิร์ฟเวอร์ไม่ได้ยืนยันว่ามีผลลัพธ์เป็นค่าว่าง
จับคู่ผลลัพธ์แต่ละข้อกับการแสดงผลที่ซื่อสัตย์
ผลลัพธ์ที่ยังไม่ได้รับการยืนยันไม่ควรแสดงเป็นรายการสำเร็จที่ว่างเปล่า
ติดตามการโต้ตอบทั้งหมด
- การติดตาม: คำขอจากเบราว์เซอร์ → ข้อมูลเข้าและการตรวจสอบสิทธิ์ของเซิร์ฟเวอร์ →การค้นหาข้อมูลที่อนุญาต → การตอบกลับ → การแสดงผลในเบราว์เซอร์ หยุดการค้นหาเมื่อการตรวจสอบที่จำเป็นล้มเหลว
- ทดสอบผู้เรียกที่อนุญาต ผู้เรียกที่ถูกปฏิเสธ ผลลัพธ์ว่าง และคำขอที่ล้มเหลวด้วยไฟล์กำหนดค่าท้องถิ่น อย่าเปิดเผยข้อมูลของนักเรียนคนอื่นเพื่อทดสอบการเข้าถึง
เบราว์เซอร์ช่วยผู้ใช้ เซิร์ฟเวอร์บังคับใช้กฎ การยืนยันตัวตน สิทธิ์ ข้อมูลที่ถูกต้อง และการค้นหาที่สำเร็จเป็นการตรวจสอบแยกต่างหาก
จัดลำดับการค้นหาที่ยอมรับได้สำเร็จนี้ใหม่
เซิร์ฟเวอร์จะบังคับใช้กฎก่อนส่งข้อมูลส่วนตัวออก
ทุกการตอบกลับของเว็บ API ต้องใช้ JSON
JSON เป็นรูปแบบที่พบบ่อย แต่ APIs สามารถใช้รูปแบบอื่นที่ระบุไว้ในเอกสารได้