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

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

• ลูกค้า - ลูกค้า;
• คำสั่งซื้อ - คำสั่งซื้อของลูกค้า
• รายการ - สินค้า

ในสถาปัตยกรรม REST ไคลเอนต์ส่งคำขอไปยังเซิร์ฟเวอร์เพื่อรับหรือแก้ไขข้อมูล และเซิร์ฟเวอร์ส่งการตอบกลับไปยังไคลเอนต์ตามคำขอของพวกเขา

คำขอ

คำขอของลูกค้าจะดำเนินการผ่าน HTTP เกือบทุกครั้ง โดยทั่วไป คำขอ HTTP ประกอบด้วยองค์ประกอบหลายอย่าง:

• วิธี HTTP;
• ชื่อ;
• ยูอาร์ไอ;
• ร้องขอร่างกาย

ด้านล่างนี้เราจะดูรายละเอียดเพิ่มเติมเกี่ยวกับส่วนประกอบแต่ละส่วน

URI และทรัพยากร

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

• ลูกค้า - ลูกค้า;
• คำสั่งซื้อ - คำสั่งซื้อของลูกค้า
• รายการ - สินค้า

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

• /clients - URI ของลูกค้าที่มีอยู่ทั้งหมด
• /clients/23 - URI ของไคลเอ็นต์เฉพาะ ได้แก่ ไคลเอ็นต์ที่มี ID=23;
• /clients/4 - URI ของไคลเอ็นต์เฉพาะ ได้แก่ ไคลเอ็นต์ที่มี ID=4

แต่นั่นไม่ใช่ทั้งหมด เราสามารถขยาย URI ได้โดยเพิ่มคำสั่ง:

• /clients/4/orders — URI ของคำสั่งซื้อทั้งหมดของลูกค้าหมายเลข 4;
• /clients/1/orders/12 - URI ของคำสั่งซื้อหมายเลข 12 ของลูกค้าหมายเลข 1

หากเราสานต่อห่วงโซ่นี้และเพิ่มสินค้า เราจะได้รับ:

• /clients/1/orders/12/items — URI ของรายการผลิตภัณฑ์ทั้งหมดในคำสั่งซื้อหมายเลข 12 ที่จัดทำโดยลูกค้าหมายเลข 1

ด้วยระดับการซ้อน สิ่งสำคัญคือการทำให้ URI ใช้งานง่าย

วิธีการ HTTP

วิธี HTTP (วิธี HTTP ภาษาอังกฤษ) เป็นลำดับของอักขระใดๆ ยกเว้นตัวควบคุมและตัวคั่น ซึ่งระบุการดำเนินการหลักบนทรัพยากร มีวิธี HTTP ทั่วไปหลายวิธี เราแสดงรายการบริการที่ใช้บ่อยที่สุดในบริการ RESTful:

• GET - ใช้เพื่อรับข้อมูลเกี่ยวกับทรัพยากรเฉพาะ (ผ่าน ID) หรือชุดของทรัพยากร
• POST - ใช้เพื่อสร้างทรัพยากรใหม่
• PUT - ใช้เพื่อเปลี่ยนทรัพยากร (ผ่าน ID)
• DELETE - ใช้เพื่อลบทรัพยากร (ผ่าน ID)

หัวเรื่อง

คำขอและการตอบกลับจะมีส่วนหัว HTTP พวกเขาส่งข้อมูลเพิ่มเติมเกี่ยวกับคำขอ (หรือการตอบกลับ) ส่วนหัวเป็นคู่คีย์-ค่า คุณสามารถอ่านรายการหัวเรื่องที่พบบ่อยที่สุดได้ในหน้าWikipedia ด้วย REST ลูกค้ามักจะสามารถส่งส่วนหัว Accept ในคำขอไปยังเซิร์ฟเวอร์ได้ จำเป็นต้องแจ้งให้เซิร์ฟเวอร์ทราบในรูปแบบใดที่ไคลเอนต์คาดว่าจะได้รับการตอบกลับ ตัวเลือกรูปแบบต่างๆ จะแสดงอยู่ในรายการประเภท MIME ที่เรียกว่า MIME (MultiPurpose Internet Mail Extensions) เป็นข้อกำหนดสำหรับการเข้ารหัสข้อมูลและการจัดรูปแบบข้อความเพื่อให้สามารถส่งผ่านอินเทอร์เน็ตได้ MIME แต่ละประเภทประกอบด้วยสองส่วน คั่นด้วยเครื่องหมายทับ: ประเภทและประเภทย่อย ตัวอย่างประเภท MIME สำหรับไฟล์ประเภทต่างๆ:

• ข้อความ - ข้อความ/ธรรมดา, ข้อความ/css, ข้อความ/html;
• รูปภาพ - รูปภาพ/png, รูปภาพ/jpeg, รูปภาพ/gif;
• เสียง - เสียง/wav, เสียง/mpeg;
• วิดีโอ - วิดีโอ/mp4, วิดีโอ/ogg;
• แอปพลิเคชัน - application/json, application/pdf, application/xml, application/octet-stream

โดยรวมแล้วคำขออาจมีส่วนหัวดังต่อไปนี้:

Accept:application/json

ส่วนหัวนี้บอกเซิร์ฟเวอร์ว่าไคลเอ็นต์คาดว่าจะได้รับการตอบกลับในรูปแบบ JSON

ขอร่างกาย

ข้อความที่ไคลเอ็นต์ส่งไปยังเซิร์ฟเวอร์ คำขอจะมีเนื้อหาหรือไม่นั้นขึ้นอยู่กับประเภทของคำขอ HTTP ตัวอย่างเช่น คำขอ GET และ DELETE โดยทั่วไปจะไม่มีเนื้อหาคำขอใดๆ แต่ PUT และ POST สามารถประกอบด้วย: ทั้งหมดนี้เกี่ยวกับวัตถุประสงค์การทำงานของประเภทคำขอ ท้ายที่สุดหากต้องการรับข้อมูลและลบออกด้วย ID (ซึ่งส่งเป็น URL) คุณไม่จำเป็นต้องส่งข้อมูลเพิ่มเติมไปยังเซิร์ฟเวอร์ แต่หากต้องการสร้างทรัพยากรใหม่ (คำขอ POST) คุณต้องถ่ายโอนทรัพยากรนี้ เช่นเดียวกับการแก้ไขทรัพยากรที่มีอยู่ ในรูปแบบ REST รูปแบบ XML หรือ JSON มักใช้เพื่อส่งเนื้อหาคำขอ รูปแบบที่พบบ่อยที่สุดคือ JSON สมมติว่าเราต้องการส่งคำขอไปยังเซิร์ฟเวอร์และในนั้นสร้างทรัพยากรใหม่ หากคุณจำได้ เป็นตัวอย่างที่เราดูแอปพลิเคชันที่จัดการคำสั่งซื้อของลูกค้า สมมติว่าเราต้องการสร้างลูกค้าใหม่ ในกรณีของเรา เราจัดเก็บข้อมูลต่อไปนี้เกี่ยวกับลูกค้า: ชื่อ อีเมล หมายเลขโทรศัพท์ จากนั้นเนื้อหาของคำขอดังกล่าวอาจเป็น JSON ต่อไปนี้:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

รวบรวมคำขอเข้าด้วยกัน

ดังนั้นเราจึงได้ดูว่าคำขอของลูกค้าประกอบด้วยอะไรบ้าง ตอนนี้เราจะยกตัวอย่างข้อความค้นหาพร้อมคำอธิบาย

คำตอบ

ลองพูดสักสองสามคำเกี่ยวกับการตอบกลับของเซิร์ฟเวอร์ คำตอบมักจะประกอบด้วยส่วนต่อไปนี้:

• รหัสตอบกลับ
• ส่วนหัว;
• ร่างกายตอบสนอง

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

รหัสตอบกลับ HTTP

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

• 201 สร้าง;
• 401 ไม่ได้รับอนุญาต;
• 507 พื้นที่เก็บข้อมูลไม่เพียงพอ

ลูกค้าเรียนรู้จากโค้ดตอบกลับเกี่ยวกับผลลัพธ์ของคำขอและกำหนดว่าจะดำเนินการใดต่อไป รหัสตอบกลับแบ่งออกเป็นหลายกลุ่ม:

• 1MXH - ข้อมูล;
• 2MXH - แจ้งเกี่ยวกับกรณีของการยอมรับและการประมวลผลคำขอของลูกค้าที่ประสบความสำเร็จ
• 3XX - แจ้งให้ลูกค้าทราบว่าเพื่อให้การดำเนินการเสร็จสมบูรณ์ได้ จำเป็นต้องทำการร้องขออีกครั้ง โดยปกติจะใช้ URI อื่น
• 4XH - ข้อผิดพลาดของไคลเอ็นต์ ตัวอย่างเช่น คำขอที่สร้างขึ้นไม่ถูกต้องหรือรหัส 404 Not Found ที่รู้จักกันดี ซึ่งอาจเกิดขึ้นเมื่อไคลเอ็นต์ร้องขอทรัพยากรที่ไม่มีอยู่จริง
• 5MXH - ข้อผิดพลาดของเซิร์ฟเวอร์ ส่งคืนไปยังไคลเอ็นต์หากการดำเนินการล้มเหลวเนื่องจากข้อผิดพลาดของเซิร์ฟเวอร์

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับรหัสทั้งหมดได้ที่นี่ ส่วนที่ 1: REST คืออะไร ส่วนที่ 3: การสร้างบริการ RESTful ใน Spring Boot