ภาพรวมของ REST ส่วนที่ 1: ส่วนที่เหลือคืออะไร

สวัสดี วันนี้เราจะศึกษาหัวข้อที่น่าสนใจและที่สำคัญที่สุดคือหัวข้อที่เป็นที่ต้องการในตลาดแรงงาน - REST เราจะแบ่งภาพรวมของ REST ออกเป็นสามส่วน:

1. ในส่วนแรก เราจะกล่าวถึงประวัติของ REST และอธิบายหลักการที่ใช้ REST

2. ในส่วนที่สอง เราจะดูว่าการสื่อสารเกิดขึ้นอย่างไรระหว่างไคลเอนต์และเซิร์ฟเวอร์ผ่านโปรโตคอล HTTP

3. ในส่วนที่สาม เราจะเขียนแอปพลิเคชัน RESTful ขนาดเล็ก ซึ่งเราจะทดสอบโดยใช้โปรแกรม Postman

บทความนี้มีไว้สำหรับผู้อ่านที่คุ้นเคยกับข้อกำหนดต่อไปนี้:

• HTTP;
• URL และ URI;
• JSON และ XML ในระดับที่น้อยกว่า
• การฉีดพึ่งพา

ส่วนที่ 1 REST คืออะไร

REST เช่นเดียวกับหลาย ๆสิ่งในโลกไอที เป็นตัวย่อสำหรับRepresentational State Transfer นี่เป็นรูปแบบสถาปัตยกรรมของการโต้ตอบระหว่างส่วนประกอบของระบบแบบกระจายในเครือข่ายคอมพิวเตอร์ พูดง่ายๆ ก็คือ REST กำหนดรูปแบบของการโต้ตอบ (การแลกเปลี่ยนข้อมูล) ระหว่างส่วนประกอบต่างๆ ของระบบ ซึ่งแต่ละองค์ประกอบอาจอยู่ในสถานที่ที่แตกต่างกัน รูปแบบสถาปัตยกรรมนี้แสดงถึงชุดข้อจำกัดที่สอดคล้องกันซึ่งนำมาพิจารณาเมื่อออกแบบระบบแบบกระจาย ข้อจำกัดเหล่านี้บางครั้งเรียกว่าหลักการ REST มีมาไม่มากเพียง 6 ชิ้นเท่านั้น เราจะพูดถึงพวกเขาในภายหลัง

ประวัติความเป็นมาของส่วนที่เหลือ

คำว่า REST ได้รับการประดิษฐ์ขึ้นโดย Roy Fielding หนึ่งในผู้สร้างโปรโตคอล HTTP ในวิทยานิพนธ์ระดับปริญญาเอกของเขาเรื่อง "รูปแบบสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์บนเครือข่าย" ในปี 2000 เราสามารถพูดได้ว่าคำว่า REST ยังใหม่อยู่ แม้ว่าแนวคิดของมันจะอยู่ที่พื้นฐานของเวิลด์ไวด์เว็บก็ตาม เราจะไม่เจาะลึกประวัติความเป็นมาของคำนี้ หากคุณต้องการเจาะลึกถึงแหล่งที่มาดั้งเดิม โปรด ดูวิทยานิพนธ์ ของ Fielding

ข้อจำกัดและหลักการของ REST

ตามที่ระบุไว้ข้างต้น REST กำหนดวิธีที่ส่วนประกอบของระบบแบบกระจายควรโต้ตอบซึ่งกันและกัน โดยทั่วไปสิ่งนี้เกิดขึ้นผ่านการตอบกลับคำขอ ส่วนประกอบที่ส่งคำขอเรียกว่าไคลเอนต์ องค์ประกอบที่ประมวลผลคำขอและส่งการตอบกลับไปยังไคลเอนต์เรียกว่าเซิร์ฟเวอร์ คำขอและการตอบกลับส่วนใหญ่มักส่งผ่าน HTTP (HyperText Transfer Protocol) โดยทั่วไปแล้ว เซิร์ฟเวอร์คือเว็บแอปพลิเคชันบางประเภท ลูกค้าสามารถเป็นได้ไม่เพียงแค่อะไรก็ได้ แต่เป็นจำนวนมาก ตัวอย่างเช่น แอปพลิเคชันมือถือที่ขอข้อมูลจากเซิร์ฟเวอร์ หรือเบราว์เซอร์ที่ส่งคำขอจากหน้าเว็บไปยังเซิร์ฟเวอร์เพื่อดาวน์โหลดข้อมูล แอปพลิเคชัน A สามารถขอข้อมูลจากแอปพลิเคชัน B ได้ จากนั้น A จะเป็นไคลเอนต์ที่เกี่ยวข้องกับ B และ B เป็นเซิร์ฟเวอร์ที่เกี่ยวข้องกับ A ในเวลาเดียวกัน A สามารถประมวลผลคำขอจาก C, D, D ฯลฯ ในกรณีนี้ แอปพลิเคชัน A เป็นทั้งเซิร์ฟเวอร์และไคลเอนต์ ทุกอย่างขึ้นอยู่กับบริบท สิ่งหนึ่งที่ชัดเจน: ส่วนประกอบที่ส่งคำขอคือไคลเอนต์ ส่วนประกอบที่รับ ประมวลผล และตอบสนองต่อคำขอคือเซิร์ฟเวอร์ อย่างไรก็ตาม ไม่ใช่ทุกระบบที่มีส่วนประกอบสื่อสารผ่านการร้องขอและตอบกลับจะเป็นระบบ REST (หรือ RESTful) เพื่อให้ระบบได้รับการพิจารณาว่าเป็น RESTful ระบบจะต้อง "เหมาะสม" ข้อจำกัด REST หกข้อ:

1. นำสถาปัตยกรรมมาสู่โมเดลไคลเอนต์-เซิร์ฟเวอร์

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

2. ขาดสภาพ

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

3. การแคช

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

4. ความสม่ำเสมอของอินเทอร์เฟซ

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

5. เลเยอร์

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

6. รหัสตามความต้องการ (ข้อจำกัดเพิ่มเติม)

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

ประโยชน์ของการพักผ่อน

แอปพลิเคชันที่ปฏิบัติตามข้อจำกัดข้างต้นทั้งหมดมีข้อดีดังต่อไปนี้: ความน่าเชื่อถือ (ไม่จำเป็นต้องจัดเก็บข้อมูลสถานะของไคลเอ็นต์ซึ่งอาจสูญหายได้)

• ประสิทธิภาพ (เนื่องจากการใช้แคช);
• ความสามารถในการขยายขนาด;
• ความโปร่งใสของระบบปฏิสัมพันธ์
• ความเรียบง่ายของอินเทอร์เฟซ
• การพกพาส่วนประกอบ
• ความสะดวกในการเปลี่ยนแปลง
• ความสามารถในการพัฒนา ปรับให้เข้ากับข้อกำหนดใหม่

ส่วนที่ 2: การสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ส่วนที่ 3: การสร้างบริการ RESTful ใน Spring Boot