Hiểu về gRPC, OpenAPI và REST và thời điểm sử dụng trong thiết kế API (2020)

Quản lý API

gRPC và REST: Hiểu về gRPC, OpenAPI, REST trong thiết kế API và thời điểm sử dụng

• Mô hình thiết kế API: Thiết kế API chủ yếu sử dụng hai mô hình là RPC và REST. Phần lớn API hiện đại được triển khai dựa trên giao thức HTTP.
• gRPC: Công nghệ triển khai API kiểu RPC sử dụng HTTP 2.0 làm giao thức truyền tải. Google và nhiều nơi khác sử dụng nhiều API kết hợp ý tưởng của RPC và HTTP.
• Ba cách sử dụng chính của HTTP:
  1. REST: Client sử dụng nguyên vẹn URL do server cung cấp và không cần hiểu định dạng URL.
  2. gRPC: Sử dụng HTTP/2, nhưng HTTP không bị lộ ra với người thiết kế API.
  3. OpenAPI: Client gọi API bằng cách sử dụng mẫu đường dẫn URL.

REST

• Đặc điểm: Client không cần hiểu định dạng URL, và URL không phải là một phần của đặc tả API.
• Ưu điểm: Có các ưu điểm của web như tính ổn định, tính nhất quán và tính phổ quát. Mô hình hướng thực thể đơn giản hơn và dễ hiểu hơn.

gRPC

• Đặc điểm: Sử dụng HTTP/2 nhưng các chi tiết của HTTP được ẩn đi. Client sử dụng API bằng cách gọi thủ tục và truyền tham số.
• Ưu điểm: Có thể dễ dàng tạo thư viện lập trình phía client và hiệu năng tốt.

OpenAPI

• Đặc điểm: Gọi API bằng mẫu đường dẫn URL, nên client phải hiểu định dạng URL.
• Ưu điểm: Có thể truy cập API chỉ với các công nghệ HTTP tiêu chuẩn. Có thể tạo thư viện lập trình phía client.

So sánh gRPC và OpenAPI

• Điểm giống nhau: Cả hai đều có thể được dùng như ngôn ngữ định nghĩa giao diện RPC (IDL).
• Khác biệt: gRPC ẩn các chi tiết HTTP, còn OpenAPI thì phơi bày các chi tiết HTTP.

Ưu điểm của REST

• Mô hình hướng thực thể: Đơn giản hơn, dễ hiểu hơn và ổn định theo thời gian.

Cách sử dụng OpenAPI

• Định nghĩa đường dẫn: Định nghĩa API bằng đường dẫn và phương thức HTTP.

Ưu và nhược điểm của OpenAPI

• Ưu điểm: Tương tự mô hình RPC nên quen thuộc với lập trình viên. Có thể ánh xạ sang các yêu cầu HTTP.
• Nhược điểm: Cần nhiều công sức để thiết kế các chi tiết HTTP.

Ưu điểm của gRPC

• Triển khai đơn giản: Việc triển khai phía server đơn giản, và có thể dễ dàng tạo thư viện phía client.
• Hiệu năng: Hiệu quả nhờ sử dụng payload nhị phân.

Nhược điểm của gRPC

• Cần phần mềm chuyên biệt: Cả client và server đều cần phần mềm chuyên biệt.
• Hạn chế khả năng của proxy: Không giống API HTTP, khó mở rộng hoặc chỉnh sửa chức năng tại proxy.

Kết luận

• Lựa chọn thiết kế API: Cần lựa chọn sau khi cân nhắc ưu và nhược điểm của REST, OpenAPI và gRPC.
• Điểm cần cân nhắc khi dùng gRPC: Phù hợp trong trường hợp không cần client phải áp dụng công nghệ gRPC, hoặc khi là API nội bộ.

[GN⁺]

Ý kiến trên Hacker News

• Có chút hối tiếc vì lẽ ra không nên học gRPC. Đã tốn rất nhiều thời gian cho việc gỡ lỗi và tinh chỉnh cấu hình

  • Dù gRPC được nói là che giấu phần nội bộ, trên thực tế vẫn cần rất nhiều gỡ lỗi và tinh chỉnh cấu hình
  • Đã lãng phí nhiều thời gian vì plugin Maven, vấn đề tương thích với HTTP2, vấn đề tường lửa, v.v.
  • Tài liệu nghèo nàn, và cũng khó làm cho thông báo lỗi trở nên dễ quan sát

• Đã xây dựng API trong thời gian dài, và từng sử dụng cả gRPC lẫn HTTP/REST

  • Thấy việc phân biệt OpenAPI với REST là khá kỳ lạ
  • OpenAPI là cách tài liệu hóa cách một HTTP API hoạt động, và có thể biểu đạt API RESTful
  • gRPC là cơ chế RPC trao đổi protocol buffers
  • gRPC hiệu quả, nhưng không mạnh mẽ bằng các thư viện HTTP

• Có kinh nghiệm làm việc tại FAANG, và cho rằng gRPC hữu ích cho việc định tuyến dịch vụ nội bộ

  • Giao thức RPC cho phép vận hành ở quy mô lớn và tốc độ cao
  • Tuy nhiên, nếu hướng đến khách hàng hoặc web thì sẽ không dùng gRPC

• Trừ khi cần streaming hai chiều, còn không thì thấy gRPC là sự lãng phí thời gian

  • Khi thực hiện các lời gọi RPC giữa các dịch vụ được triển khai bằng nhiều ngôn ngữ khác nhau, cần rất nhiều middleware

• Trong một dự án dùng gRPC, ban đầu đã áp dụng vì lý do hiệu năng, nhưng sau đó chuyển sang JSON API

  • Thiếu kinh nghiệm với gRPC, và dự án đã thất bại do nhiều vấn đề khác nhau

• Khi dùng connectrpc, đang giải quyết được các vấn đề của gRPC

  • Có thể dễ dàng lấy các tệp proto của bên thứ ba thông qua buf.build
  • Tính năng tự động tạo SDK rất hữu ích

• Cho rằng trải nghiệm phát triển với gRPC tệ hơn REST

  • Cần thêm công cụ, và mã client được sinh ra thì phức tạp

• Roy Fielding từng nhắc rằng với REST API, chỉ cần biết URI ban đầu và media type đã được chuẩn hóa

• Không thích dùng gRPC trong trung tâm dữ liệu

  • Hiệu năng không quá cao, và chất lượng client mã nguồn mở thấp
  • Với API nền web, thích tính dễ đọc của JSON hơn, nhưng lại có vấn đề không khớp kiểu dữ liệu

• Cảm thấy gRPC rất khó tiếp cận bên ngoài Google

  • Client gRPC JS nặng nề và thiếu minh bạch
  • So với sự đơn giản của REST, thấy cách triển khai này là sai lầm