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

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

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

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

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

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

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

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

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

ประวัติของ REST

คำว่า REST ได้รับการแนะนำโดย Roy Fielding ซึ่งเป็นหนึ่งในผู้สร้างโปรโตคอล HTTP ในปริญญาเอกของเขา วิทยานิพนธ์เรื่อง "Architectural Styles and the Design of Network-based Software Architectures" ในปี 2000 แม้ว่าคำว่า REST จะยังเรียกได้ว่ายังเด็กอยู่ เราจะไม่ลงลึกถึงประวัติของคำนี้ หากคุณต้องการเจาะลึกถึงแหล่งข้อมูลหลัก โปรด ดูที่ วิทยานิพนธ์ ของ Fielding

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

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

1. สถาปัตยกรรมแบบไคลเอ็นต์-เซิร์ฟเวอร์

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

2. ไร้สัญชาติ

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

3. แคชได้

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

4. อินเตอร์เฟสที่เหมือนกัน

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

5. ชั้น

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

6. รหัสตามความต้องการ (ไม่บังคับ)

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

ข้อดีของสถาปัตยกรรม RESTful

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

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

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