GRPC แตกต่างจาก REST อย่างไร?

ฉันกำลังอ่านคำอธิบายของ GRPCและแผนผังนี้เป็นที่สนใจ:

เลเยอร์การขนส่งทำงานอย่างไร? ถ้ามันผ่านเครือข่าย ... ทำไมถึงเรียกว่า RPC? ที่สำคัญกว่านั้นสิ่งนี้แตกต่างจาก REST ที่ใช้ API สำหรับชั้นบริการอย่างไร (คลาสในไคลเอนต์ที่มีเมธอดที่สร้างคำขอ http)

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

HTTP / 2 ยังรองรับการเชื่อมต่อแบบสองทิศทางและการเชื่อมต่อแบบอะซิงโครนัส ดังนั้นจึงเป็นไปได้ที่เซิร์ฟเวอร์จะติดต่อกับไคลเอนต์เพื่อส่งข้อความได้อย่างมีประสิทธิภาพ (การตอบกลับแบบ async / การแจ้งเตือน ฯลฯ )

ในขณะที่ทั้ง REST และ gRPC สามารถสร้างต้นขั้วไคลเอนต์ / เซิร์ฟเวอร์ได้ (โดยใช้บางอย่างเช่น swagger สำหรับ REST) ​​REST มีชุดการเรียก 'ฟังก์ชัน' หลักที่ จำกัด (หรือคำกริยา):

+ ----------- + ---------------- +
| คำกริยา HTTP | CRUD |
+ ----------- + ---------------- +
| รับ | อ่าน |
| PUT | อัปเดต / แทนที่ |
| แพทช์ | ปรับปรุง / แก้ไข |
| ลบ | ลบ |
+ ----------- + ---------------- +

ในขณะที่ gRPC คุณสามารถกำหนดการเรียกใช้ฟังก์ชันประเภทใดก็ได้รวมทั้งซิงโครนัส / อะซิงโครนัสทิศทางเดียว / สองทิศทาง (สตรีม) เป็นต้น

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

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

REST ไม่ต้องการ JSON หรือ HTTP / 1.1

คุณสามารถสร้างบริการ RESTful ที่ส่งข้อความ protobuf (หรืออะไรก็ได้) ผ่าน HTTP / 2

คุณสามารถสร้างบริการ RESTful ที่ส่ง JSON ผ่าน HTTP / 2

คุณสามารถสร้างบริการ RESTful ที่ส่งข้อความ protobuf ผ่าน HTTP / 1.1

บริการ RESTful ไม่ใช่ "แฮ็ก" ที่อยู่เหนือ HTTP / xx แต่เป็นบริการตามหลักการสถาปัตยกรรมพื้นฐานที่ทำให้ HTTP เวอร์ชันใด ๆ ประสบความสำเร็จ (เช่นความสามารถในการแคชของคำขอ GET และความสามารถในการเล่นซ้ำของคำขอ PUT)

gRPC, SOAP และอื่น ๆ เป็นเหมือนแฮ็ก - แฮ็กที่อยู่ด้านบนของ HTTP เพื่ออุโมงค์บริการรูปแบบ RPC ผ่าน HTTP เพื่อกำหนดเส้นทางไปยังข้อ จำกัด ของไฟร์วอลล์และมิดเดิลแวร์ นั่นไม่จำเป็นต้องเป็นเรื่องเลวร้าย บางครั้งคุณอาจต้องการบริการรูปแบบ RPC แทนที่จะเป็น REST และเราต้องอยู่ในโลกที่มิดเดิลบ็อกซ์ยากที่จะแทนที่

หากคุณไม่มีเวลาอ่านคำจำกัดความที่แท้จริงของ REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

มี TLDR อยู่เสมอ เวอร์ชันบนวิกิพีเดีย:

https://en.wikipedia.org/wiki/Representational_state_transfer

หากคุณต้องการบริการสไตล์ RPC แน่นอนว่า gRPC นั้นยอดเยี่ยมมาก หากคุณต้องการใช้งานบนเว็บหรือต้องการประโยชน์ทั้งหมดที่มาพร้อมกับบริการสไตล์ RESTful ให้สร้างบริการสไตล์ RESTful และถ้าช้าเกินไปที่จะทำให้ข้อมูลเป็นอนุกรม / deserialize ข้อมูลในรูปแบบ JSON ในบริการพักผ่อนของคุณคุณสามารถใช้ protobuf หรืออะไรก็ได้

หาก gRPC เป็นเวอร์ชัน 2 ก็จะเป็น SOAP เวอร์ชัน 2 สิ่งที่ไม่น่ากลัวเช่น SOAP

และไม่คุณไม่สามารถ "เรียกใช้ฟังก์ชันใด ๆ " ในคำขอ GET ของคุณและมีบริการ RESTful ได้

สิ่งสุดท้าย: หากคุณจะใช้ protobufs กับบริการ RESTful โปรดทำให้ถูกต้องโดยใช้ส่วนหัวประเภทเนื้อหา ฯลฯ ด้วยเหตุนี้คุณจึงสามารถรองรับทั้ง JSON และ protobuf ได้อย่างง่ายดาย

ก้าวลงจากกล่อง SOAP ของฉันตอนนี้ .. ;)

ข้อได้เปรียบที่ใหญ่ที่สุดของ gRPC เหนือ REST คือการรองรับ HTTP / 2 ผ่านปู่ HTTP 1.1 ข้อได้เปรียบที่ใหญ่ที่สุดของ HTTP / 2 บน HTTP 1.1 คือ 'HTTP / 2 อนุญาตให้เซิร์ฟเวอร์ "พุช" เนื้อหา "...

ฉันรู้สึกเสมอว่า gRPC และ REST เป็นสองสิ่งที่แตกต่างกันอย่างสิ้นเชิง

REST ดีที่สุดสำหรับบริการที่เน้นทรัพยากร มิฉะนั้นเราสามารถใช้ gRPC เพื่อประสิทธิภาพสูง

REST คือระดับอินเทอร์เน็ตสำหรับการพูดคุยของผู้ใช้ปลายทางด้วยบริการของเรา gRPC เป็นระดับอินทราเน็ตสำหรับบริการภายในที่พูดคุยกัน

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