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

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

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

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

คำขอ

คำขอของไคลเอนต์มักจะทำโดยใช้โปรโตคอล HTTP โดยทั่วไป คำขอ HTTP ประกอบด้วยองค์ประกอบหลายอย่าง:

• วิธี HTTP
• หัวข้อ
• ยูอาร์ไอ
• ร่างกายร้องขอ

ด้านล่างนี้เราจะพิจารณาแต่ละองค์ประกอบโดยละเอียดยิ่งขึ้น

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

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

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

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

• /customers — URI ของลูกค้าที่มีอยู่ทั้งหมด
• /customers/23 — URI ของลูกค้าเฉพาะ เช่น ลูกค้าที่มี ID=23
• /customers/4 — URI ของลูกค้าเฉพาะ เช่น ลูกค้าที่มี ID=4

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

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

หากเราขยายต่อไปโดยเพิ่มผลิตภัณฑ์มากขึ้น เราจะได้รับ:

• /customers/1/orders/12/items — URI ของรายการสินค้าทั้งหมดตามลำดับที่ 12 ที่จัดทำโดยลูกค้าลำดับที่ 1

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

วิธี HTTP

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

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

ส่วนหัว

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

• ข้อความ — ข้อความ/ธรรมดา, ข้อความ/css, ข้อความ/html
• รูปภาพ — รูปภาพ/png, รูปภาพ/jpeg, รูปภาพ/gif
• เสียง — เสียง/wav, เสียง/mpeg
• วิดีโอ — วิดีโอ/mp4, วิดีโอ/ogg
• แอปพลิเคชัน — แอปพลิเคชัน/json, แอปพลิเคชัน/pdf, แอปพลิเคชัน/xml, แอปพลิเคชัน/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" : "+1 (222) 333-4444"
}

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

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

คำตอบ

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

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

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

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

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

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

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

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

ภาพรวมของ REST ตอนที่ 3: สร้างบริการ RESTful บน Spring Boot