gRPC và REST khác nhau ở điểm nào?
gRPC và REST là hai cách bạn có thể thiết kế API. API là cơ chế cho phép 2 thành phần phần mềm giao tiếp với nhau bằng cách sử dụng một tập hợp các định nghĩa và giao thức. Trong gRPC, một thành phần (máy khách) sẽ gọi các hàm cụ thể trong một thành phần phần mềm khác (máy chủ). Trong REST, thay vì gọi các hàm, máy khách sẽ yêu cầu hoặc cập nhật dữ liệu trên máy chủ.
gRPC là gì?
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.
REST là gì?
REST là một cách tiếp cận kiến trúc phần mềm xác định một tập hợp các quy tắc để trao đổi dữ liệu giữa các thành phần phần mềm. REST dựa trên HTTP, giao thức truyền thông tiêu chuẩn của web. API RESTful quản lý giao tiếp giữa máy khách và máy chủ thông qua các động từ HTTP như POST, GET, PUT và DELETE cho các hoạt động tạo, đọc, cập nhật và xóa. Tài nguyên phía máy chủ được xác định bởi một URL được gọi là điểm cuối.
REST hoạt động như sau:
- Máy khách thực hiện yêu cầu tạo, sửa đổi, hoặc xóa một tài nguyên trên máy chủ
- Yêu cầu chứa điểm cuối tài nguyên và cũng có thể bao gồm các tham số bổ sung
- Máy chủ phản hồi, trả lại toàn bộ tài nguyên cho máy khách sau khi hoạt động hoàn tất
- Phản hồi chứa dữ liệu ở định dạng JSON và mã trạng thái
Các API được xây dựng bằng cách sử dụng các nguyên tắc REST được gọi là API RESTful hoặc API REST.
Tại sao các tổ chức sử dụng gRPC và REST?
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.
Những điểm tương đồng giữa gRPC và REST là gì?
REST và gRPC có một số điểm tương đồng vốn có với các phương pháp tiếp cận kiến trúc API.
Cơ chế trao đổi dữ liệu
Cả hai đều cho phép hai thành phần phần mềm, một máy khách và một máy chủ, giao tiếp và trao đổi dữ liệu dựa trên một bộ quy tắc chung. Các quy tắc này áp dụng bất kể mỗi thành phần phần mềm hoạt động nội bộ như thế nào.
Giao tiếp dựa trên HTTP
Cả hai đều truyền dữ liệu thông qua cơ chế phản hồi yêu cầu HTTP, giao thức truyền thông hiệu quả ưa thích của web. Tuy nhiên, trong gRPC, điều này bị ẩn với nhà phát triển, trong khi ở REST, điều này rõ ràng hơn.
Tính linh hoạt khi triển khai
Bạn có thể triển khai cả REST và gRPC bằng một loạt các ngôn ngữ lập trình. Chất lượng này làm cho cả hai đều có tính di động cao trong các môi trường lập trình. Điều này dẫn đến khả năng tương tác tối ưu với sự hỗ trợ gần như phổ quát.
Tính phù hợp với các hệ thống phân phối, có thể điều chỉnh quy mô
Cả gRPC và REST đều sử dụng:
- Giao tiếp không đồng bộ, vì vậy máy khách và máy chủ có thể giao tiếp mà không làm gián đoạn hoạt động
- Thiết kế phi trạng thái, vì vậy máy chủ không cần phải nhớ trạng thái của máy khách
Điều này có nghĩa là các nhà phát triển có thể sử dụng gRPC và REST để xây dựng các hệ thống chống lỗi với một số lượng lớn các yêu cầu đồng thời. Bạn có thể xây dựng các hệ thống phân phối, có thể điều chỉnh quy mô với nhiều khách hàng.
Nguyên tắc kiến trúc: gRPC so với REST
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.
Những điểm khác biệt chính khác giữa gRPC và REST
Những điểm khác biệt chính khác giữa gRPC và REST
Ngoài kiểu kiến trúc, gRPC và REST còn có những điểm khác biệt vốn có khác.
Liên kết máy khách-máy chủ
REST được liên kết ít phụ thuộc, có nghĩa là máy khách và máy chủ không cần biết bất cứ điều gì về việc triển khai của bên kia. Liên kết ít phụ thuộc này làm cho API dễ dàng phát triển hơn theo thời gian. Điều này là do sự thay đổi về định nghĩa máy chủ không nhất thiết phải thay đổi mã trong máy khách.
gRPC được liên kết phụ thuộc, có nghĩa là máy khách và máy chủ phải có quyền truy cập vào cùng một tệp proto. Bất kỳ bản cập nhật nào cho tệp đều yêu cầu cập nhật trong cả máy chủ và máy khách.
Tạo mã
gRPC cung cấp một lựa chọn sẵn có các tính năng tạo mã gốc phía máy khách và phía máy chủ. Có sẵn nhiều ngôn ngữ do protoc, trình biên dịch Protocol Buffers. Sau khi xác định cấu trúc trong tệp proto, gRPC tạo mã phía máy khách và phía máy chủ. Tạo mã giúp cho việc phát triển API ít tốn thời gian hơn.
Mặt khác, REST không cung cấp bất kỳ cơ chế tạo mã tích hợp nào, vì vậy các nhà phát triển phải sử dụng các công cụ bổ sung của bên thứ ba nếu họ yêu cầu tính năng này. Tìm hiểu thêm về tạo mã.
Phát trực tuyến hai chiều
gRPC cung cấp giao tiếp phát trực tuyến hai chiều. Điều này có nghĩa là cả máy khách và máy chủ có thể gửi và nhận nhiều yêu cầu và phản hồi cùng một lúc trên một kết nối duy nhất.
REST không cung cấp tính năng này.
Thời điểm sử dụng gRPC so với REST
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.
Tóm tắt các điểm khác biệt giữa gRPC và REST
| gRPC API |
REST API |
|
| Đó là gì? |
Một hệ thống để tạo và sử dụng các API dựa trên mô hình giao tiếp máy khách-máy chủ trong Remote Procedure Call (RPC). |
Một tập hợp các quy tắc định hình quá trình trao đổi dữ liệu có cấu trúc giữa một máy khách và một máy chủ. |
| Phương pháp thiết kế |
Thiết kế theo hướng dịch vụ. Máy khách yêu cầu máy chủ thực hiện một dịch vụ hoặc chức năng mà có thể hoặc không ảnh hưởng đến tài nguyên máy chủ. |
Thiết kế theo định hướng thực thể. Máy khách yêu cầu máy chủ tạo, chia sẻ hoặc sửa đổi tài nguyên. |
| Mô hình truyền thông |
Nhiều tùy chọn như đơn phân, một máy chủ giao tiếp với nhiều máy khách, một máy khách giao tiếp với nhiều máy chủ, nhiều máy khách giao tiếp với nhiều máy chủ. |
Đơn phân. Một máy khách giao tiếp với một máy chủ. |
| Thực hiện |
Yêu cầu phần mềm gRPC ở cả máy khách và máy chủ để hoạt động. |
Bạn có thể triển khai trên máy khách và máy chủ ở nhiều định dạng khác nhau mà không cần sử dụng chung phần mềm. |
| Truy cập dữ liệu |
Các lần gọi (hàm) dịch vụ. |
Nhiều điểm cuối dưới dạng URL để xác định tài nguyên. |
| Dữ liệu trả về |
Trong kiểu trả về cố định của dịch vụ như được xác định trong tệp Protocol Buffer. |
Trong một cấu trúc cố định (thường là JSON), được xác định bởi máy chủ. |
| Liên kết máy khách-máy chủ |
Được liên kết phụ thuộc. Cả máy khách và máy chủ đều cần cùng một tệp Protocol Buffer xác định định dạng dữ liệu. |
Liên kết ít phụ thuộc. Máy khách và máy chủ không biết về chi tiết nội bộ. |
| Tạo mã tự động |
Tính năng tích hợp sẵn. |
Yêu cầu các công cụ của bên thứ ba. |
| Phát trực tuyến hai chiều |
Hiện tại. |
Không hiện diện. |
| Trường hợp sử dụng phù hợp nhất |
Kiến trúc dịch vụ vi mô hiệu suất cao hoặc nặng về dữ liệu. |
Các nguồn dữ liệu đơn giản trong đó tài nguyên được xác định rõ ràng. |
AWS có thể hỗ trợ các yêu cầu của bạn về gRPC và REST như thế nào?
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.
