ทำความเข้าใจ gRPC, OpenAPI และ REST และช่วงเวลาที่ควรใช้ในการออกแบบ API (2020)

 (cloud.google.com)
1 คะแนน โดย GN⁺ 2025-01-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การจัดการ API

gRPC และ REST: ทำความเข้าใจ gRPC, OpenAPI, REST และช่วงเวลาที่ควรใช้ในการออกแบบ API

  • โมเดลการออกแบบ API: โดยหลักแล้วการออกแบบ API ใช้สองโมเดลคือ RPC และ REST API สมัยใหม่ส่วนใหญ่ถูกพัฒนาบนพื้นฐานของโปรโตคอล HTTP
  • gRPC: เทคโนโลยีสำหรับสร้าง RPC API ที่ใช้ HTTP 2.0 เป็นโปรโตคอลขนส่ง Google และบริษัทอื่น ๆ ใช้ API จำนวนมากที่ผสานแนวคิดของ RPC และ HTTP เข้าด้วยกัน
  • สามวิธีหลักในการใช้งาน HTTP:
    1. REST: ไคลเอนต์ใช้ URL ที่เซิร์ฟเวอร์ให้มาได้โดยตรง และไม่จำเป็นต้องเข้าใจรูปแบบของ URL
    2. gRPC: ใช้ HTTP/2 แต่รายละเอียดของ HTTP จะไม่ถูกเปิดเผยต่อผู้ออกแบบ API
    3. OpenAPI: ไคลเอนต์เรียกใช้ API โดยใช้เทมเพลตเส้นทาง URL

REST

  • ลักษณะเด่น: ไคลเอนต์ไม่จำเป็นต้องเข้าใจรูปแบบของ URL และ URL ไม่ใช่ส่วนหนึ่งของข้อกำหนด API
  • ข้อดี: มีข้อดีแบบเดียวกับเว็บ เช่น ความเสถียร ความสม่ำเสมอ และความเป็นสากล โมเดลที่ยึดตามเอนทิตีนั้นเรียบง่ายและเข้าใจได้ง่ายกว่า

gRPC

  • ลักษณะเด่น: ใช้ HTTP/2 แต่ซ่อนรายละเอียดของ HTTP เอาไว้ ไคลเอนต์ใช้งาน API โดยการเรียกโพรซีเยอร์และส่งพารามิเตอร์
  • ข้อดี: สร้างไลบรารีสำหรับการเขียนโปรแกรมฝั่งไคลเอนต์ได้ง่าย และมีประสิทธิภาพดี

OpenAPI

  • ลักษณะเด่น: เรียกใช้ API ผ่านเทมเพลตเส้นทาง URL และไคลเอนต์ต้องเข้าใจรูปแบบของ URL
  • ข้อดี: เข้าถึง API ได้ด้วยเทคโนโลยี HTTP มาตรฐานเพียงอย่างเดียว และสามารถสร้างไลบรารีสำหรับการเขียนโปรแกรมฝั่งไคลเอนต์ได้

การเปรียบเทียบ gRPC กับ OpenAPI

  • ความเหมือน: ทั้งคู่สามารถใช้เป็นภาษาอธิบายอินเทอร์เฟซแบบ RPC (IDL) ได้
  • ความต่าง: gRPC ซ่อนรายละเอียดของ HTTP ขณะที่ OpenAPI เปิดเผยรายละเอียดของ HTTP

ข้อดีของ REST

  • โมเดลที่ยึดตามเอนทิตี: เรียบง่าย เข้าใจง่าย และมีความเสถียรแม้เวลาจะผ่านไป

วิธีใช้งาน OpenAPI

  • การกำหนดเส้นทาง: นิยาม API โดยใช้เส้นทางและเมธอด HTTP

ข้อดีและข้อเสียของ OpenAPI

  • ข้อดี: คล้ายกับโมเดล RPC จึงคุ้นเคยสำหรับโปรแกรมเมอร์ และสามารถแมปกับคำขอ HTTP ได้
  • ข้อเสีย: ต้องใช้ความพยายามมากในการออกแบบรายละเอียดของ HTTP

ข้อดีของ gRPC

  • การพัฒนาที่เรียบง่าย: การพัฒนาฝั่งเซิร์ฟเวอร์ทำได้ง่าย และสามารถสร้างไลบรารีฝั่งไคลเอนต์ได้อย่างสะดวก
  • ประสิทธิภาพ: มีประสิทธิภาพสูงเพราะใช้ payload แบบไบนารี

ข้อเสียของ gRPC

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

บทสรุป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-24
ความคิดเห็นจาก Hacker News

  • รู้สึกเสียดายที่ไปเรียนรู้ gRPC เพราะเสียเวลาไปมากกับการดีบักและการปรับแต่งการตั้งค่า

    • แม้ gRPC จะบอกว่าซ่อนรายละเอียดภายในไว้ แต่ในความเป็นจริงกลับต้องใช้การดีบักและการปรับแต่งการตั้งค่าจำนวนมาก
    • เสียเวลาไปมากกับ Maven plugin, ปัญหาความเข้ากันได้กับ HTTP2, ปัญหาไฟร์วอลล์ เป็นต้น
    • เอกสารไม่ดีพอ และทำให้ข้อความผิดพลาดสังเกตและตรวจสอบได้ยาก

  • สร้าง API มายาวนาน และเคยใช้ทั้ง gRPC และ HTTP/REST

    • คิดว่าการแยก OpenAPI ออกจาก REST เป็นเรื่องแปลก
    • OpenAPI คือวิธีการจัดทำเอกสารพฤติกรรมของ HTTP API และสามารถใช้แสดง RESTful API ได้
    • gRPC คือกลไก RPC ที่รับส่ง protocol buffers
    • gRPC มีประสิทธิภาพ แต่ไม่ได้ทรงพลังเท่ากับไลบรารี HTTP

  • มีประสบการณ์ทำงานที่ FAANG และคิดว่า gRPC มีประโยชน์สำหรับการทำ routing ของบริการภายใน

    • โปรโตคอล RPC ทำให้รองรับงานขนาดใหญ่และความเร็วสูงได้
    • แต่ถ้าเป็นงานสำหรับลูกค้าหรือเว็บ จะไม่เลือกใช้ gRPC

  • คิดว่า gRPC เป็นการเสียเวลา เว้นแต่จะใช้การสตรีมแบบสองทิศทาง

    • เมื่อต้องทำ RPC call ระหว่างบริการที่พัฒนาด้วยหลายภาษา จำเป็นต้องมี middleware จำนวนมาก

  • ในโปรเจกต์ที่ใช้ gRPC เคยนำมาใช้ด้วยเหตุผลด้านประสิทธิภาพ แต่สุดท้ายเปลี่ยนไปใช้ JSON API

    • มีประสบการณ์กับ gRPC ไม่มากพอ และโปรเจกต์ล้มเหลวเพราะปัญหาหลายอย่าง

  • กำลังแก้ปัญหาของ gRPC ด้วยการใช้ connectrpc

    • สามารถนำเข้าไฟล์ proto ของ third-party ได้ง่ายผ่าน buf.build
    • ความสามารถในการสร้าง SDK อัตโนมัติมีประโยชน์มาก

  • คิดว่าประสบการณ์การพัฒนาด้วย gRPC แย่กว่า REST

    • ต้องใช้เครื่องมือเพิ่มเติม และโค้ดไคลเอนต์ที่สร้างขึ้นมีความซับซ้อน

  • Roy Fielding เคยกล่าวว่า REST API ต้องรู้เพียง URI เริ่มต้นและ media type ที่เป็นมาตรฐาน

  • ไม่ชอบใช้ gRPC ภายในดาต้าเซ็นเตอร์

    • ประสิทธิภาพไม่ได้สูงมาก และคุณภาพของโอเพนซอร์สไคลเอนต์ต่ำ
    • สำหรับ API บนเว็บ ชอบความอ่านง่ายของ JSON แต่ก็มีปัญหาเรื่อง type mismatch

  • รู้สึกว่า gRPC เข้าถึงได้ยากนอกโลกของ Google

    • gRPC JS client มีขนาดใหญ่และไม่โปร่งใส
    • เมื่อเทียบกับความเรียบง่ายของ REST แล้ว รู้สึกว่ามันถูกทำออกมาผิดทาง