gRPC กับ REST แตกต่างกันอย่างไร


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

gRPC กับ REST แตกต่างกันอย่างไร

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

อ่านเพิ่มเติมเกี่ยวกับ API »

gRPC คืออะไร

gRPC เป็นสถาปัตยกรรม API แบบโอเพนซอร์สและระบบที่ควบคุมโดย Cloud Native Computing Foundation gRPC ใช้โมเดลการเรียกใช้กระบวนการระยะไกล (RPC) ในขณะที่โมเดล RPC เป็นการใช้งานในวงกว้าง gRPC เป็นการนำไปใช้แบบเฉพาะเจาะจง

RPC คืออะไร

ใน RPC การสื่อสารระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์จะทำงานราวกับว่าคำขอของ API ฝั่งไคลเอ็นต์เป็นการดำเนินการภายใน หรือคำขอเป็นโค้ดเซิร์ฟเวอร์ภายใน

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

gRPC แตกต่างจาก RPC อย่างไร

gRPC เป็นระบบที่ใช้ RPC แบบดั้งเดิมที่มีการเพิ่มประสิทธิภาพหลายรายการ ตัวอย่างเช่น gRPC ใช้ Protocol Buffer และ HTTP 2 ในการส่งข้อมูล

นอกจากนี้ยังทำให้นักพัฒนาไม่ต้องจัดการกลไกการแลกเปลี่ยนข้อมูล ตัวอย่างเช่น การใช้งาน RPC API อย่างแพร่หลายอีกรูปแบบหนึ่งอย่าง OpenAPI กำหนดให้นักพัฒนาเชื่อมโยงแนวคิด RPC กับโปรโตคอล HTTP แต่ gRPC ตัดการสื่อสาร HTTP พื้นฐานนั้น การเพิ่มประสิทธิภาพเหล่านี้ทำให้ gRPC รวดเร็วขึ้น ง่ายต่อการใช้งาน และใช้งานร่วมกับเว็บได้ดีกว่าการใช้ RPC อื่นๆ 

REST คืออะไร

REST เป็นวิธีการทางสถาปัตยกรรมซอฟต์แวร์ที่กำหนดชุดกฎในการแลกเปลี่ยนข้อมูลระหว่างส่วนประกอบซอฟต์แวร์ REST ใช้ HTTP ซึ่งเป็นโปรโตคอลการสื่อสารมาตรฐานของเว็บ RESTful API จัดการการสื่อสารระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ผ่านคำกริยา HTTP เช่น POST, GET, PUT และ DELETE เพื่อสร้าง อ่าน อัปเดต และลบการดำเนินการ ทรัพยากรฝั่งเซิร์ฟเวอร์จะถูกระบุโดย URL ที่เรียกว่าตำแหน่งข้อมูล 

REST ทำงานดังนี้

  1. ไคลเอ็นต์จัดทำคำขอเพื่อสร้าง แก้ไข หรือลบทรัพยากรบนเซิร์ฟเวอร์
  2. คำขอประกอบด้วยตำแหน่งข้อมูลทรัพยากรและอาจรวมถึงพารามิเตอร์เพิ่มเติม
  3. เซิร์ฟเวอร์ตอบสนองโดยส่งกลับทรัพยากรทั้งหมดให้กับไคลเอ็นต์เมื่อการดำเนินการเสร็จสมบูรณ์
  4. การตอบสนองประกอบด้วยข้อมูลในรูปแบบ JSON และโค้ดสถานะ

API ที่สร้างขึ้นโดยใช้แนวทาง REST จะเรียกว่า RESTful API หรือ REST API

อ่านเกี่ยวกับ RESTful APIs »

ทำไมองค์กรจึงใช้ gRPC และ REST

gRPC และ REST เป็น 2 วิธีที่แตกต่างกันในการพัฒนา API

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

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

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

gRPC และ REST มีความคล้ายคลึงกันอย่างไร

REST และ gRPC มีความคล้ายคลึงกันโดยธรรมชาติบางอย่างในแง่แนวทางสถาปัตยกรรมของ API

กลไกการแลกเปลี่ยนข้อมูล

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

การสื่อสารโดยใช้ HTTP

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

ความยืดหยุ่นในการนำไปใช้

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

ความเหมาะสมสำหรับระบบแบบกระจายที่ปรับขนาดได้

ทั้ง gRPC และ REST ใช้ฟังก์ชันต่อไปนี้

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

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

หลักการสถาปัตยกรรมระหว่าง gRPC กับ REST

ในขณะที่ REST และ gRPC มีฟังก์ชันที่คล้ายกัน แต่โมเดลพื้นฐานมีความแตกต่างกันอย่างมีนัยสำคัญในสถาปัตยกรรม

โมเดลการสื่อสาร

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

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

การดำเนินการที่เรียกใช้ได้บนเซิร์ฟเวอร์

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

createNewOrder(customer_id, item_id, item_quantity) -> order_id

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

POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id

ในขณะที่คุณสามารถออกแบบ gRPC API ด้วยวิธีการที่มุ่งเน้นเอนทิตีนี้ได้ แต่ก็ไม่ได้เป็นข้อจำกัดของตัวระบบแต่อย่างใด

รูปแบบการแลกเปลี่ยนข้อมูล

เมื่อใช้ REST API โครงสร้างข้อมูลที่ส่งระหว่างส่วนประกอบซอฟต์แวร์มักจะแสดงในรูปแบบการแลกเปลี่ยนข้อมูล JSON โดยสามารถส่งรูปแบบข้อมูลอื่นๆ ได้ เช่น XML และ HTML JSON ง่ายต่อการอ่านและมีความยืดหยุ่น แม้ว่าจะต้องมีการแปลงเป็นอนุกรมและแปลเป็นภาษาเขียนโปรแกรม

ในทางตรงกันข้าม gRPC ใช้รูปแบบ Protocol Buffer (Protobuf) โดยค่าเริ่มต้น แม้ว่าจะยังคงรองรับ JSON แบบดั้งเดิม เซิร์ฟเวอร์กำหนดโครงสร้างข้อมูลโดยใช้ Interface Description Language (IDL) ของ Protocol Buffer ในไฟล์ข้อกำหนด Proto จากนั้น gRPC จะแปลงโครงสร้างเป็นอนุกรมในรูปแบบไบนารี แล้วแปลงอนุกรมเป็นภาษาเขียนโปรแกรมที่ระบุ กลไกนี้จะทำให้ดำเนินการรวดเร็วกว่าการใช้ JSON ซึ่งไม่ได้ถูกบีบอัดในระหว่างการส่ง Protocol Buffer ไม่ใช่ภาษาที่มนุษย์สามารถอ่านได้ ซึ่งแตกต่างจาก REST API ที่ใช้ร่วมกับ JSON

อ่านเพิ่มเติมเกี่ยวกับ JSON »

ความแตกต่างที่สำคัญอื่นๆ ระหว่าง gRPC กับ REST

ความแตกต่างที่สำคัญอื่นๆ ระหว่าง gRPC กับ REST

นอกเหนือจากรูปแบบสถาปัตยกรรมแล้ว gRPC และ REST มีความแตกต่างโดยธรรมชาติอื่นๆ อีก

การเชื่อมโยงระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์

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

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

การสร้างโค้ด

gRPC มีตัวเลือกคุณสมบัติการสร้างโค้ดดั้งเดิมของฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ในตัว โดยมีให้บริการในหลายภาษา เนื่องจาก Protoc คอมไพเลอร์ Protocol Buffer หลังจากกำหนดโครงสร้างในไฟล์ Proto แล้ว gRPC จะสร้างโค้ดฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ การสร้างโค้ดทำให้การพัฒนา API ใช้เวลาน้อยลง

ในทางกลับกัน REST ไม่ได้มีกลไกการสร้างโค้ดในตัว ดังนั้นนักพัฒนาจะต้องใช้เครื่องมือของบุคคลที่สามเพิ่มเติมหากต้องใช้คุณสมบัตินี้ เรียนรู้เพิ่มเติมเกี่ยวกับการสร้างโค้ด

การสตรีมแบบสองทิศทาง

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

REST ไม่ได้มีคุณสมบัตินี้

เมื่อใดที่ควรใช้ gRPC หรือ REST

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

กรณีการใช้งานสำหรับ REST API มีดังต่อไปนี้

  • สถาปัตยกรรมบนเว็บ
  • API สาธารณะเพื่อความสะดวกในการทำความเข้าใจโดยผู้ใช้ภายนอก
  • การสื่อสารข้อมูลที่เรียบง่าย

gRPC แตกต่างจาก REST โดยได้รับการออกแบบมาโดยเฉพาะเพื่อให้นักพัฒนาสามารถสร้าง API ประสิทธิภาพสูงสำหรับสถาปัตยกรรมไมโครเซอร์วิสทั่วทั้งศูนย์ข้อมูลแบบกระจายได้ gRPC เหมาะสำหรับระบบภายในที่ต้องใช้การสตรีมแบบเรียลไทม์และการโหลดข้อมูลขนาดใหญ่มากกว่า นอกจากนั้น gRPC ยังเหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิสที่ประกอบด้วยภาษาโปรแกรมหลายภาษาเมื่อ API ไม่มีแนวโน้มที่จะเปลี่ยนแปลงเมื่อเวลาผ่านไป

gRPC API จะเหมาะสำหรับกรณีการใช้งานต่อไปนี้

  • ระบบประสิทธิภาพสูง
  • โหลดข้อมูลสูง
  • แอปพลิเคชันแบบเรียลไทม์หรือการสตรีม

หมายเหตุเกี่ยวกับการพัฒนาซอฟต์แวร์เว็บ

ในขณะที่ HTTP เป็นเว็บโปรโตคอลหลัก แต่ HTTP เวอร์ชันต่างๆ ก็มีระดับการปรับใช้ทั่วทั้งเว็บเบราว์เซอร์และเว็บเซิร์ฟเวอร์ที่แตกต่างกัน

gRPC API ใช้ HTTP 2 เสมอ และ REST API มักจะใช้ HTTP 1.1 ซึ่งไม่ได้เป็นโปรโตคอล HTTP เดียวกัน ในขณะที่ HTTP 2 เป็นเว็บโปรโตคอลที่แพร่หลายในปัจจุบัน แต่ก็ไม่มีการรองรับเบราว์เซอร์แบบสากล ซึ่งแตกต่างจาก HTTP 1.1 การรองรับเบราว์เซอร์แบบจำกัดนี้อาจทำให้ gRPC เป็นตัวเลือกที่น่าสนใจน้อยกว่าสำหรับนักพัฒนาที่ต้องการสนับสนุนแอปพลิเคชันบนเว็บ

สรุปความแตกต่างระหว่าง gRPC กับ REST

 

gRPC API

REST API

คืออะไร

ระบบการสร้างและใช้ API ใช้โมเดลการสื่อสารเซิร์ฟเวอร์ของไคลเอ็นต์การเรียกใช้กระบวนการระยะไกล (RPC) 

ชุดของกฎที่กำหนดการแลกเปลี่ยนข้อมูลที่มีโครงสร้างระหว่างไคลเอ็นต์และเซิร์ฟเวอร์

แนวทางการออกแบบ

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

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

โมเดลการสื่อสาร

หลายตัวเลือก เช่น แบบเดี่ยว เซิร์ฟเวอร์หนึ่งไปยังหลายไคลเอ็นต์ ไคลเอ็นต์หนึ่งไปยังหลายเซิร์ฟเวอร์ และหลายไคลเอ็นต์ไปยังหลายเซิร์ฟเวอร์

แบบเดี่ยว ไคลเอ็นต์เดียวสื่อสารกับเซิร์ฟเวอร์เดียว

การปรับใช้

ต้องใช้ซอฟต์แวร์ gRPC ทั้งบนไคลเอ็นต์และฝั่งเซิร์ฟเวอร์เพื่อใช้งาน

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

การเข้าถึงข้อมูล

การเรียกใช้บริการ (ฟังก์ชัน)

ตำแหน่งข้อมูลหลายจุดในรูปแบบของ URL ในการกำหนดทรัพยากร

ข้อมูลที่ส่งคืน

ในประเภทข้อมูลส่งคืนแบบคงที่ของบริการตามที่กำหนดไว้ในไฟล์ Protocol Buffer

ในโครงสร้างแบบคงที่ (มักจะเป็น JSON) ที่กำหนดโดยเซิร์ฟเวอร์

การเชื่อมโยงระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์

เชื่อมโยงแบบ Tight Coupling ทั้งไคลเอ็นต์และเซิร์ฟเวอร์ต้องมีไฟล์ Protocol Buffer เดียวกันที่กำหนดรูปแบบข้อมูล

เชื่อมโยงแบบ Loose Coupling ไคลเอ็นต์และเซิร์ฟเวอร์ไม่ทราบรายละเอียดภายใน

การสร้างโค้ดอัตโนมัติ

คุณสมบัติในตัว

ต้องใช้เครื่องมือของบุคคลที่สาม

การสตรีมแบบสองทิศทาง

มี

ไม่มี

เหมาะที่สุดสำหรับ

สถาปัตยกรรมไมโครเซอร์วิสที่มีประสิทธิภาพสูงหรือมีข้อมูลปริมาณมาก

แหล่งที่มาของข้อมูลที่ไม่ซับซ้อนที่มีการกำหนดทรัพยากรไว้อย่างดี

AWS รองรับข้อกำหนด gRPC และ REST ของคุณได้อย่างไร

Amazon Web Services (AWS) มีบริการและเครื่องมือมากมายที่จะช่วยนักออกแบบ API ในการสร้าง เรียกใช้ รวมถึงจัดการแอปพลิเคชันและบริการที่ใช้ API ที่ทันสมัย สำหรับข้อมูลเพิ่มเติม โปรดอ่านเกี่ยวกับการสร้างแอปพลิเคชันที่ทันสมัยบน AWS

ต่อไปนี้คือตัวอย่างข้อเสนอ AWS ที่รองรับข้อกำหนด API ของคุณได้

  • เกตเวย์ของ Amazon API ช่วยให้นักพัฒนาสามารถสร้าง เผยแพร่ และจัดการ API ในวงกว้างได้ เกตเวย์ของ API ช่วยให้คุณสามารถสร้าง RESTful API ที่เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิสที่มีคอนเทนเนอร์และแอปพลิเคชันบนเว็บ
  • Elastic Load Balancing (ELB) กระจายการรับส่งข้อมูลเครือข่ายเพื่อปรับปรุงความสามารถในการปรับขนาดแอปพลิเคชัน โดยสามารถกำหนดเส้นทางและปรับสมดุลโหลดการรับส่งข้อมูล gRPC ระหว่างไมโครเซอร์วิส หรือระหว่างไคลเอ็นต์และบริการที่เปิดใช้งาน gRPC การทำงานนี้ช่วยให้สามารถนำระบบจัดการการรับส่งข้อมูลของ gRPC มาใช้ในสถาปัตยกรรมได้อย่างราบรื่น โดยไม่ต้องเปลี่ยนแปลงโครงสร้างพื้นฐานใดๆ ของไคลเอ็นต์หรือบริการของลูกค้า
  • Amazon Virtual Private Cloud (Amazon VPC) Lattice เป็นบริการเครือข่ายแอปพลิเคชันที่เชื่อมต่อ ตรวจสอบ และรักษาความปลอดภัยของการสื่อสารระหว่างบริการของคุณอย่างต่อเนื่อง ปรับขนาดทรัพยากรการประมวลผลและเครือข่ายโดยอัตโนมัติเพื่อรองรับเวิร์กโหลด HTTP, HTTPS และ gRPC ที่มีแบนวิดท์สูง

เริ่มต้นใช้งาน gRPC และ REST บน AWS โดยสร้างบัญชีวันนี้

ขั้นตอนถัดไปกับ AWS

เรียนรู้วิธีเริ่มต้นใช้งาน gRPC บน AWS

เรียนรู้วิธีเริ่มต้นใช้งาน REST บน AWS