gRPC và REST khác nhau ở điểm nào?

RPC là gì?

Trong RPC, giao tiếp máy khách-máy chủ hoạt động như thể các yêu cầu API của máy khách là một hoạt động cục bộ hoặc yêu cầu là mã máy chủ nội bộ.

Trong RPC, máy khách gửi yêu cầu đến một tiến trình trên máy chủ luôn lắng nghe các lệnh gọi từ xa. Trong yêu cầu, nó chứa hàm máy chủ để gọi, cùng với bất kỳ tham số nào cần truyền. RPC API sử dụng giao thức như HTTP, TCP hoặc UDP làm cơ chế trao đổi dữ liệu cơ bản.

gRPC khác với RPC như thế nào?

gRPC là một hệ thống thực hiện RPC truyền thống với một số tối ưu hóa. Ví dụ, gRPC sử dụng Protocol Buffer và HTTP 2 để truyền dữ liệu.

gRPC cũng tóm tắt cơ chế trao đổi dữ liệu từ nhà phát triển. Ví dụ, một triển khai RPC API được sử dụng rộng rãi khác, OpenAPI, yêu cầu các nhà phát triển ánh xạ các khái niệm RPC tới giao thức HTTP. Nhưng gRPC tóm tắt giao tiếp HTTP cơ bản. Những tối ưu hóa này giúp gRPC nhanh hơn, dễ triển khai hơn và thân thiện với web hơn các triển khai RPC khác. 

gRPC và REST là hai cách tiếp cận khác nhau để phát triển API.

API hoạt động tương tự như việc đặt món ăn từ một nhà hàng thông qua một menu. Tại bất kỳ nhà hàng nào, khách hàng (máy khách) có thể đặt thức ăn từ menu (API), trong đó có các món ăn cố định. Điều này được thông báo đến nhà bếp (máy chủ) để chuẩn bị món ăn theo yêu cầu và gửi cho khách hàng. Khách hàng không cần phải biết nhà bếp thực hiện đơn đặt món như thế nào, chỉ cần biết kết quả. Tiêu chuẩn hóa các định dạng menu có nghĩa là khách hàng và nhà bếp biết cách sử dụng chúng.

Nếu không có API, sẽ không có thỏa thuận chung về cách giao tiếp giữa các ứng dụng hoặc dịch vụ phần mềm khác nhau. Các lập trình viên của hai ứng dụng riêng biệt sẽ cần phải trao đổi với nhau để xác định cách xây dựng việc trao đổi dữ liệu mỗi lần.

Các loại kiến trúc API khác nhau như gRPC và REST tồn tại, vì những kiến trúc khác nhau có thể phù hợp hơn với các trường hợp sử dụng khác nhau trong một tổ chức. Nhà thiết kế API phải chọn kiến trúc máy khách-máy chủ ưa thích của họ dựa trên yêu cầu hệ thống.

Trong khi REST và gRPC cung cấp một chức năng tương tự, các mô hình cơ bản khác nhau đáng kể về kiến trúc của chúng.

Mô hình truyền thông

Bằng cách sử dụng API REST, máy khách gửi một yêu cầu API REST duy nhất đến một máy chủ và sau đó máy chủ sẽ gửi một phản hồi duy nhất để trả lời. Máy khách phải đợi máy chủ phản hồi trước khi tiếp tục hoạt động. Cơ chế này là một mô hình phản hồi yêu cầu và là một kết nối dữ liệu đơn phân (một-một). 

Ngược lại, với gRPC, máy khách có thể gửi một hoặc nhiều yêu cầu API đến máy chủ có thể dẫn đến một hoặc nhiều câu trả lời từ máy chủ. Kết nối dữ liệu có thể là đơn phân (một-một), phát trực tuyến máy chủ (một-nhiều), phát trực tuyến máy khách (nhiều-một) hoặc phát trực tuyến hai chiều (nhiều-nhiều). Cơ chế này là mô hình giao tiếp phản hồi máy khách và có thể thực hiện được vì gRPC dựa trên HTTP 2. 

Các hoạt động có thể gọi trên máy chủ

Trong API gRPC, các hoạt động máy chủ có thể gọi được xác định bởi các dịch vụ, còn được gọi là các hàm hoặc thủ tục. Máy khách gRPC gọi các hàm này giống như bạn sẽ gọi một hàm nội bộ trong một ứng dụng. Đây được gọi là thiết kế theo hướng dịch vụ. Dưới đây là một ví dụ:

createNewOrder(customer_id, item_id, item_quantity) -> order_id

Trong REST, có một tập hợp giới hạn các động từ yêu cầu HTTP mà máy khách có thể sử dụng trên các tài nguyên máy chủ được xác định bởi một URL. Máy khách gọi chính tài nguyên đó. Đây được gọi là thiết kế theo hướng thực thể. Thiết kế theo hướng thực thể phù hợp tốt với các phương pháp lập trình theo hướng đối tượng. Dưới đây là một ví dụ:

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

Mặc dù bạn có thể thiết kế các API gRPC theo cách tiếp cận theo hướng thực thể, nhưng đây không phải là một ràng buộc của chính hệ thống.

Định dạng trao đổi dữ liệu

Với API REST, các cấu trúc dữ liệu được truyền giữa các thành phần phần mềm thường được thể hiện ở định dạng trao đổi dữ liệu JSON. Có thể truyền các định dạng dữ liệu khác như XML và HTML. JSON rất dễ đọc và linh hoạt, mặc dù phải được tuần tự hóa và dịch sang ngôn ngữ lập trình.

Ngược lại, gRPC sử dụng định dạng Protobuf Buffer (Protobuf) theo mặc định, mặc dù cũng hỗ trợ JSON gốc. Máy chủ xác định cấu trúc dữ liệu bằng cách sử dụng ngôn ngữ mô tả giao diện (IDL) Protocol Buffer trong tệp đặc tả proto. gRPC sau đó tuần tự hóa cấu trúc thành định dạng nhị phân và sau đó giải mã hóa thành bất kỳ ngôn ngữ lập trình được chỉ định nào. Cơ chế này làm cho nó nhanh hơn so với sử dụng JSON, không bị nén trong quá trình truyền. Protocol Buffer có định dạng mà con người không thể đọc được, không giống như API REST được sử dụng với JSON.

Tìm hiểu về JSON »

REST hiện là kiến trúc API phổ biến nhất cho các dịch vụ web và kiến trúc dịch vụ vi mô. REST phổ biến do được triển khai đơn giản và ánh xạ cấu trúc dữ liệu, khả năng đọc và tính linh hoạt. Thật dễ dàng cho các lập trình viên mới bắt đầu phát triển API RESTful cho các ứng dụng của họ, cho dù là để phát triển dịch vụ web hay dịch vụ vi mô nội bộ.

Dưới đây là các trường hợp sử dụng API REST:

• Kiến trúc dựa trên web
• API công khai để người dùng bên ngoài dễ hiểu
• Truyền thông dữ liệu đơn giản

gRPC, không giống như REST, được thiết kế đặc biệt để cho phép các nhà phát triển tạo ra các API hiệu suất cao cho các kiến trúc dịch vụ vi mô trên các trung tâm dữ liệu phân phối. gRPC phù hợp hơn đối với các hệ thống nội bộ yêu cầu phát trực tuyến theo thời gian thực và tải dữ liệu lớn. gRPC cũng phù hợp với kiến trúc dịch vụ vi mô bao gồm một số ngôn ngữ lập trình khi API không có khả năng thay đổi theo thời gian.

API gRPC phù hợp hơn với các trường hợp sử dụng sau đây:

• Hệ thống hiệu suất cao
• Tải dữ liệu cao
• Ứng dụng thời gian thực hoặc phát trực tuyến

Một lưu ý về phát triển phần mềm web

Trong khi HTTP là giao thức web lõi, các phiên bản khác nhau của HTTP tồn tại với mức độ áp dụng khác nhau trên các trình duyệt web và máy chủ web.

API gRPC luôn sử dụng HTTP 2 và API REST thường sử dụng HTTP 1.1, không phải là cùng một giao thức HTTP. Mặc dù HTTP 2 hiện là một giao thức web phổ biến, nhưng không có hỗ trợ trình duyệt phổ quát, không giống như HTTP 1.1. Việc hỗ trợ trình duyệt hạn chế này có thể làm cho gRPC trở thành một lựa chọn kém hấp dẫn hơn cho các nhà phát triển muốn hỗ trợ các ứng dụng web.

Amazon Web Services (AWS) có một loạt các dịch vụ và công cụ để giúp các nhà thiết kế API xây dựng, chạy và quản lý các ứng dụng và dịch vụ hiện đại dựa trên API. Để biết thêm thông tin, hãy đọc về cách xây dựng các ứng dụng hiện đại trên AWS.

Dưới đây là ví dụ về các dịch vụ AWS có thể hỗ trợ đáp ứng các yêu cầu API của bạn:

• Cổng API Amazon cho phép các nhà phát triển tạo, xuất bản và quản lý API trên quy mô lớn. Với Cổng API, bạn có thể xây dựng các API RESTful được tối ưu hóa cho các kiến trúc dịch vụ vi mô và ứng dụng web được container hóa.
• Cân bằng tải linh hoạt (ELB) phân phối lưu lượng mạng để cải thiện khả năng điều chỉnh quy mô ứng dụng. Dịch vụ này có thể định tuyến và cân bằng tải lưu lượng gRPC giữa các dịch vụ vi mô hoặc giữa các máy khách và dịch vụ hỗ trợ gRPC. Điều này cho phép đưa vào liền mạch khả năng quản lý lưu lượng gRPC trong các kiến trúc mà không thay đổi bất kỳ cơ sở hạ tầng cơ bản nào trên máy khách hoặc dịch vụ của khách hàng.
• Mạng Đám mây riêng ảo của Amazon (Amazon VPC) là một dịch vụ mạng ứng dụng liên tục kết nối, giám sát và bảo mật thông tin liên lạc giữa các dịch vụ của bạn. Tự động điều chỉnh quy mô tài nguyên mạng và điện toán để hỗ trợ khối lượng công việc HTTP, HTTPS và gRPC băng thông cao.

Bắt đầu sử dụng gRPC và REST trên AWS bằng cách tạo tài khoản ngay hôm nay.