8.1 แนวทาง API ระยะไกล
โปรแกรมเมอร์ทุกคนทำผิดพลาดเหมือนกันเมื่อสร้างสถาปัตยกรรมไคลเอ็นต์เซิร์ฟเวอร์ พวกเขาเริ่มจัดการกับคำขอไปยังเซิร์ฟเวอร์เป็นการเรียกใช้เมธอด
คุณต้องการเริ่มต้นกระบวนการสร้างรายงานบนเซิร์ฟเวอร์ ทำไมไม่ส่งคำขอเช่น:
http://server.com/startDocumentGeneration?paramsแล้วจะดาวน์โหลดรายงานหลังจากทำเสร็จแล้วได้อย่างไร? ในการทำเช่นนี้เราจะเขียนวิธีอื่น:
http://server.com/getDocumentเซิร์ฟเวอร์จะHttpSessionเก็บข้อมูลในเอกสารของเรา และทันทีที่เอกสารถูกสร้างขึ้น เซิร์ฟเวอร์จะคืนเอกสารนั้นให้
วิธีการที่ดี หรือไม่?
วิธีการนี้แย่มากจริงๆ สิ่งที่เซิร์ฟเวอร์ต้องจำหมายเลขเอกสาร กล่าวอีกนัยหนึ่ง เพื่อที่จะประมวลผลการเรียกใช้เมธอดใหม่ได้อย่างถูกต้อง เซิร์ฟเวอร์ต้องจดจำผลลัพธ์ของการเรียกใช้เมธอดก่อนหน้านี้
บนเว็บ นี่เป็นปัญหาใหญ่ อินเทอร์เน็ตอาจหายไป เบราว์เซอร์อาจปิด หน้าเว็บสามารถโหลดซ้ำหรือคลิกลิงก์โดยไม่ตั้งใจได้ เป็นต้น และเซิร์ฟเวอร์จะยังคงจัดเก็บข้อมูลเมกะไบต์จากคำขอของผู้ใช้ก่อนหน้า ...
สำหรับการทำงานกับเซิร์ฟเวอร์อย่างสะดวกสบาย คุณไม่สามารถคาดหวังได้ว่าคุณจะมีข้อมูลของคำขอก่อนหน้านี้ไปยังเซิร์ฟเวอร์อยู่เสมอ
แล้วจะเรียกเมธอดของเซิร์ฟเวอร์ได้อย่างไร? คำตอบที่ถูกต้องจะแย่มาก: ไม่มีทาง!
8.2 วิธีที่เหลือ
โปรแกรมเมอร์กลับไปสู่พื้นฐานและจำได้ว่าในขั้นต้นคำขอมีเส้นทางไปยังไฟล์บนเซิร์ฟเวอร์:
http://server.com/path?paramsและเราตัดสินใจที่จะใช้แนวทางนี้ให้เกิดประโยชน์สูงสุด
ตอนนี้เซิร์ฟเวอร์ถือเป็นที่เก็บข้อมูลที่มองเห็นได้จากภายนอกในรูปแบบของต้นไม้
หากคุณต้องการรับรายชื่อผู้ใช้ทั้งหมด ให้เรียกแบบสอบถาม:
http://server.com/usersหากคุณต้องการรับข้อมูลเกี่ยวกับผู้ใช้ 113 ให้เรียกใช้แบบสอบถาม:
http://server.com/users/113และอื่น ๆ ทั้งหมดในเส้นเลือดเดียวกัน
เซิร์ฟเวอร์ถูกมองว่าเป็นที่เก็บข้อมูลที่มองเห็นได้จากภายนอกในรูปแบบของต้นไม้
สามารถ รับข้อมูลได้ - ร้องขอGETแก้ไข - ร้องขอ POSTและลบ - ร้องขอ DELETE
8.3 ไม่มีสถานะ
โปรโตคอล REST ของการโต้ตอบระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ต้องมีเงื่อนไขต่อไปนี้: ระหว่างช่วงเวลาระหว่างคำขอจากลูกค้า จะไม่มีข้อมูลเกี่ยวกับสถานะของไคลเอ็นต์ถูกเก็บไว้บนเซิร์ฟเวอร์
คำขอทั้งหมดจากลูกค้าต้องสร้างขึ้นในลักษณะที่เซิร์ฟเวอร์ได้รับข้อมูลทั้งหมดที่จำเป็นในการดำเนินการตามคำขอใน แต่ละครั้ง สถานะเซสชันถูกบันทึกไว้ในฝั่งไคลเอ็นต์
ในระหว่างการประมวลผลคำขอของไคลเอ็นต์ จะถือว่าไคลเอ็นต์อยู่ในสถานะเปลี่ยนผ่าน สถานะแอปพลิเคชันแต่ละสถานะจะแสดงด้วยลิงก์ที่สามารถเรียกใช้ได้ในครั้งต่อไปที่ไคลเอ็นต์เข้าชม
8.4 ความสม่ำเสมอของอินเทอร์เฟซ
เส้นทางทั้งหมดที่ใช้ในการดึงวัตถุจากเซิร์ฟเวอร์เป็นมาตรฐาน ซึ่งสะดวกมาก โดยเฉพาะอย่างยิ่งหากคุณได้รับข้อมูลจากเซิร์ฟเวอร์ REST อื่น
อินเทอร์เฟซวัตถุทั้งหมดต้องเป็นไปตามเงื่อนไขสามประการ:
การระบุทรัพยากร
ทรัพยากรทั้งหมดถูกระบุในคำขอโดยใช้ URI ทรัพยากรภายในเซิร์ฟเวอร์แยกจากมุมมองที่ส่งคืนไปยังไคลเอนต์ ตัวอย่างเช่น เซิร์ฟเวอร์อาจส่งข้อมูลจากฐานข้อมูลเป็น HTML, XML หรือ JSON ซึ่งไม่ใช่ประเภทการจัดเก็บภายในเซิร์ฟเวอร์
จัดการทรัพยากรผ่านมุมมอง
หากไคลเอนต์จัดเก็บการเป็นตัวแทนของทรัพยากร รวมถึงข้อมูลเมตา ก็จะมีข้อมูลเพียงพอที่จะแก้ไขหรือลบทรัพยากรบนเซิร์ฟเวอร์
ข้อความ "อธิบายตนเอง"
แต่ละข้อความมีข้อมูลเพียงพอที่จะเข้าใจวิธีจัดการ ตัวอย่างเช่น หากคุณต้องการข้อมูลเกี่ยวกับผู้ใช้ เซิร์ฟเวอร์จะส่งคืนวัตถุ JSON ให้คุณ ซึ่งจะมีช่องชื่อและที่อยู่
ไม่ควรมีสถานการณ์ที่ลูกค้าจำเป็นต้องรู้ว่าตัวเลขตัวแรกในการตอบกลับคืออายุ และตัวที่สองคือวันเดือนปีเกิด
8.5 การแคช
วิธีการ REST จะถือว่ามีการร้องขอข้อมูลผ่านโปรโตคอล HTTP ดังนั้นวัตถุจะได้รับโดยการเรียกคำขอ GET ซึ่งหมายความว่าทรัพยากรทั้งหมดที่ได้รับผ่านคำขอ GET จะต้องอยู่ภายใต้กฎทั้งหมดสำหรับการแคชทรัพยากร HTTP เช่นเดียวกับทรัพยากรทั้งหมด
นั่นคือ ข้อมูลที่ได้รับผ่าน REST API จะถูกแคชในลักษณะเดียวกับทรัพยากรแบบสแตติกใดๆ บนเว็บเซิร์ฟเวอร์ ความงาม :)