Lưu ý của Người dịch: Khi thiết kế kiến ​​trúc microservice, xây dựng API và lựa chọn công nghệ giao tiếp giữa các dịch vụ, vẫn còn những điểm mù về kiến ​​thức trong cách hiểu và ứng dụng REST và gRPC. Gần đây tôi đã đọc bài viết nước ngoài này: So sánh chi tiết về REST và gRPC. cả hai một cách chi tiết. Cuối tuần mình có thời gian dịch, mong có thể giúp ích cho mọi người! .

Trong một thời gian dài, REST là "tiêu chuẩn" duy nhất để xây dựng API. Trong những năm gần đây, các lựa chọn thay thế mới đã xuất hiện. Năm 2015, Facebook phát hành GraphQL, tiếp theo là Google vào năm 2016 với gRPC, được sử dụng rộng rãi. Trong bài viết này, chúng tôi sẽ tập trung vào gRPC và so sánh nó với REST.

Tổng quan

Bảng bên dưới sẽ phác thảo những điểm chính được thảo luận trong bài viết này và cho thấy REST và gRPC thực sự tỏa sáng ở đâu.

chủ đề	NGHỈ NGƠI	gRPC
tiêu chuẩn hóa	không có tiêu chuẩn	được xác định rõ
khuôn mẫu	tập trung vào tài nguyên	Tập trung vào phương pháp phục vụ
mô hình dịch vụ	dòng một nhân dân tệ	Luồng đơn nhất, luồng khách, luồng máy chủ và luồng hai chiều
Yêu cầu	Bất kỳ phân tích cú pháp HTTP, Json nào	Ngôn ngữ lập trình cần hỗ trợ HTTP/2, gRPC
thiết kế API	mã đầu tiên	Thiết kế đầu tiên
Định dạng dữ liệu mặc định	JSON (Json là gì?)	Nguyên mẫu
Hỗ trợ trình duyệt WEB	Hỗ trợ gốc của trình duyệt	gRPC WEB
dụng cụ	công cụ trưởng thành	Công cụ ngôn ngữ lập trình cụ thể

tiêu chuẩn hóa

Một trong những thiếu sót của REST là thiếu tiêu chuẩn hóa. REST không phải là một tiêu chuẩn API vì nó là một mô hình. Nhiều người có những ý nghĩa khác nhau khi nói về nó. Đối với hầu hết mọi người, thuật ngữ "REST API" có nghĩa là API JSON qua HTTP; đối với các thông số kỹ thuật khác, REST được sử dụng thay thế cho nhau với một số thông số kỹ thuật như HATEOAS hoặc JSON:API.

Thuật ngữ REST thậm chí không liên quan đến HTTP. Khi làm việc với REST API, có thể xảy ra nhiều nhầm lẫn. Ví dụ: người tiêu dùng có thể mong đợi tính bình thường hoặc khả năng lưu vào bộ nhớ đệm của một số điểm cuối API REST nhất định, ngay cả khi không được xác định rõ ràng.

Để so sánh, gRPC được xác định rất rõ ràng. Ví dụ: việc triển khai gRPC qua HTTP/2 rất chi tiết.

Sự khác biệt cơ bản

Mô hình của REST và gRPC không giống nhau.

REST là tất cả về tài nguyên, có thể được truy xuất và thao tác. Nếu chúng tôi sử dụng sách làm tài nguyên mẫu thì API REST thường cung cấp các điểm cuối sau:

• NHẬN /sách : Tìm kiếm tất cả sách, với các tham số để lọc và phân trang kết quả
• NHẬN /sách/{id} : Truy xuất sổ ID được chỉ định
• POST /sách :Tạo sách
• XÓA /books/{id} : Xóa sách

Hầu hết các API REST dựa trên HTTP đều tuân theo mẫu này. Điều này không sao, nhưng một số tình huống khó diễn đạt dưới dạng API REST. Ví dụ: điều gì sẽ xảy ra nếu bạn muốn tạo nhiều sách mà không gọi POST/books nhiều lần cho mỗi cuốn sách (vì hiệu suất, tính bình thường hoặc các lý do khác)? Tôi có nên tạo điểm cuối POST/sách/đợt không? Đây vẫn là “RESTful” phải không? Mặc dù dễ giải quyết về mặt kỹ thuật nhưng các cuộc thảo luận kéo dài thường diễn ra giữa các nhà phát triển.

Mặt khác, gRPC là một khung RPC tập trung vào các phương thức dịch vụ. Nếu chúng tôi lấy API Sách làm ví dụ, sử dụng gRPC, phương pháp sau sẽ được sử dụng để tạo BookService:

• Lấy Sách()
• Lấy Sách()
• TạoSách()
• XóaSách()

Bạn có thể đặt tên cho các phương thức này bất cứ điều gì bạn muốn và đặt bất kỳ tham số bắt buộc nào. Nếu bây giờ chúng ta muốn thêm một phương thức để tạo nhiều sách, không có gì ngăn cản chúng ta thêm phương thức CreateBooks(). gRPC mang lại nhiều "tự do" hơn khi thiết kế API vì có ít hạn chế (tự áp đặt) hơn.

mô hình dịch vụ

gRPC hỗ trợ bốn phương thức dịch vụ:

• Luồng đơn nhất: Gửi một yêu cầu và nhận một phản hồi.
• Truyền phát máy chủ: Gửi một yêu cầu và nhận nhiều phản hồi.
• Truyền phát ứng dụng khách: Gửi nhiều yêu cầu và nhận một phản hồi duy nhất.
• Luồng hai chiều: gửi nhiều yêu cầu và nhận nhiều phản hồi.

So với REST chỉ hỗ trợ các yêu cầu đơn nhất, gRPC có lợi thế rất tốt. Việc hỗ trợ các chế độ dịch vụ khác trong API REST yêu cầu sử dụng các giao thức khác nhau, chẳng hạn như các sự kiện do máy chủ gửi hoặc ổ cắm web, vốn không "RESTful" cho lắm.

Yêu cầu

API REST thường "chỉ hoạt động" với bất kỳ loại phiên bản HTTP nào. Miễn là ngôn ngữ lập trình có ứng dụng khách HTTP và thư viện để phân tích cú pháp JSON thì việc sử dụng API REST là một điều dễ dàng.

gRPC rõ ràng yêu cầu hỗ trợ HTTP/2, nếu không nó sẽ không hoạt động. Trong những năm gần đây, vấn đề này đã ít xảy ra hơn vì hầu hết các framework đều đã thêm hỗ trợ cho HTTP/2.

Vì gRPC yêu cầu tạo mã (để tạo sơ khai máy khách hoặc máy chủ) nên chỉ hỗ trợ một số ngôn ngữ lập trình, hãy xem danh sách ngôn ngữ lập trình.

thiết kế API

API REST thường là kết quả của quá trình triển khai chúng, được gọi là "code-first". Mặc dù có thể thiết kế API bằng OpenAPI trước rồi tạo các nhánh máy chủ, nhưng đây không phải là cách tiếp cận được nhiều nhà phát triển áp dụng. Nếu có định nghĩa OpenAPI thì định nghĩa OpenAPI rất có thể được tạo từ quá trình triển khai API. Do đó, việc định nghĩa và triển khai API được kết hợp chặt chẽ. Những thay đổi đối với các lớp mô hình có thể dẫn đến những thay đổi về API vô tình phá vỡ đặc tả giao diện.

gRPC sử dụng một cách tiếp cận khác, trong đó API phải được xác định trước khi có thể triển khai (được gọi là "thiết kế đầu tiên"). Sau đó tạo sơ khai máy khách và máy chủ dựa trên định nghĩa API. Điều này cần phải được tính toán trước vì API không thể được triển khai trực tiếp.

Cả hai phương pháp đều có ưu và nhược điểm. Thông thường, cách tiếp cận API REST cho phép lặp lại nhanh chóng; với gRPC, việc thay đổi định nghĩa API trước khi điều chỉnh việc triển khai API có thể gây khó chịu. Tuy nhiên, bằng cách xác định rõ ràng API sẽ an toàn hơn và các thay đổi API ít tùy tiện hơn.

Định dạng dữ liệu

Cả REST và gRPC đều có thể sử dụng các định dạng khác nhau để truyền dữ liệu. Hầu hết các API REST đều sử dụng JSON, trong khi gRPC sử dụng Bộ đệm giao thức theo mặc định, một định dạng lưu trữ dữ liệu có cấu trúc nhẹ và hiệu quả, vì vậy chúng tôi sẽ so sánh cả hai.

JSON có hỗ trợ hạn chế cho các loại dữ liệu; ví dụ: số lượng lớn cần được biểu diễn dưới dạng chuỗi. JOSON là một định dạng văn bản dễ đọc. Việc tuần tự hóa tên trường chiếm một số không gian. Trong một số ngôn ngữ lập trình, sự phản chiếu cũng cần thiết để giải tuần tự hóa các thông báo JSON, việc này diễn ra chậm.

Như đã đề cập ở trên, API gRPC và các loại thông báo tương ứng trước tiên được xác định là Bộ đệm giao thức. Mỗi tin nhắn đều được gõ mạnh và đối với các ngôn ngữ lập trình được hỗ trợ, mã có thể được tạo tự động để (hủy) tuần tự hóa tin nhắn. Vì đây là định dạng nhị phân và không tuần tự hóa tên trường nên nó sử dụng ít không gian hơn thông báo JSON tương đương. Tuy nhiên, có những nhược điểm: không thể đọc được tin nhắn được tuần tự hóa và cần có định nghĩa Protobuf để giải tuần tự hóa tin nhắn, điều này có thể ảnh hưởng đến trải nghiệm của nhà phát triển.

Ví dụ JSON bên dưới sẽ chiếm khoảng 66 byte (trừ khoảng trắng).

                        
                          { "người": [ { "tên": "Max", "tuổi": 23 }, { "tên": "Mike", "tuổi": 52 } ] }

                        
                      

Thông báo protobuf được tuần tự hóa tương đương sẽ chỉ sử dụng 19 byte.

                        
                          0x0A070A034D617810170A080A0448616E731034

                        
                      

tin tức lớn

Protobuf được thiết kế để tuần tự hóa và giải tuần tự hóa các tin nhắn trong bộ nhớ. Vì vậy, không nên sử dụng Protobuf/gRPC để truyền tải những thông điệp lớn. Hầu hết việc triển khai gRPC đều có giới hạn mặc định là 4 MB cho một tin nhắn.

Việc xử lý khối lượng dữ liệu lớn (chẳng hạn như tải tệp lên) khá đơn giản bằng cách sử dụng API REST. Các tệp đã nhận có thể được coi là luồng, sử dụng rất ít bộ nhớ. Điều này đòi hỏi nhiều công việc hơn trong gRPC: tệp phải được chia thành nhiều phần ở phía người gửi. Mỗi đoạn sau đó sẽ được gửi đến máy chủ dưới dạng một tin nhắn riêng biệt thông qua phương thức phát trực tuyến của máy khách. Máy chủ nhận từng đoạn và xây dựng một luồng dữ liệu, dẫn đến hoạt động tương tự như API REST.

Khả năng tương thích của trình duyệt

Khả năng tương thích của trình duyệt là nơi REST thực sự tỏa sáng. Nó được hỗ trợ nguyên bản bởi các trình duyệt WEB, vì vậy có thể dễ dàng sử dụng API REST trong các ứng dụng WEB.

gRPC không được trình duyệt hỗ trợ trực tiếp vì nó yêu cầu hỗ trợ HTTP/2 rõ ràng và quyền truy cập vào một số tính năng HTTP/2 nhất định mà trình duyệt web không cung cấp. Để khắc phục, bạn có thể sử dụng giao thức web gRPC để cung cấp giao thức này cho trình duyệt WEB. Đối với một số ngôn ngữ lập trình, hỗ trợ Web gRPC đã được đưa vào khung. Đối với các trường hợp khác, cần có proxy để chuyển đổi luồng gRPC thành luồng web gRPC và ngược lại. So với API REST không yêu cầu phụ thuộc, API gRPC khó sử dụng hơn trên WEB.

Một giải pháp thay thế có thể là sử dụng chuyển mã JSON, cho phép các nhà phát triển hiển thị API gRPC dưới dạng API REST.

dụng cụ

Các công cụ gRPC và REST rất khác nhau giữa các ngôn ngữ lập trình và framework. Trong một số trường hợp, gRPC mang lại cảm giác "bản địa" hơn, trong khi trong các trường hợp khác, các công cụ REST lại tiên tiến hơn. Hỗ trợ ngôn ngữ lập trình cho gRPC thậm chí còn quan trọng hơn vì cần có các công cụ để tạo sơ khai máy khách và máy chủ cho các ngôn ngữ lập trình cụ thể. gRPC không được dùng nữa đối với các ngôn ngữ lập trình không được hỗ trợ.

Vì API REST đã tồn tại lâu hơn nên có nhiều công cụ hơn để giúp xây dựng, thử nghiệm và triển khai API REST. Chức năng của chúng thường cao cấp hơn các công cụ gRPC.

bản tóm tắt

Không có câu trả lời rõ ràng cho "Tôi nên sử dụng REST hay gRPC?" Một số API có các trường hợp sử dụng riêng mà gRPC hoặc REST có thể phù hợp hơn.

Cả REST và gRPC đều có những ưu điểm và nhược điểm riêng.

Việc sử dụng API REST từ ứng dụng WEB thường dễ dàng hơn. REST cũng đang được sử dụng rộng rãi hơn, giúp các nhà phát triển sử dụng nó đơn giản hơn.

gRPC chắc chắn có lợi thế khi nói đến giao tiếp từ máy chủ đến máy chủ (ví dụ: giữa các vi dịch vụ). Có thể chia sẻ định nghĩa API chính xác và tạo ứng dụng khách API bằng nhiều ngôn ngữ lập trình là một lợi thế rất lớn.

dotNET Brotherhood-Tài khoản công cộng

Tập trung vào công nghệ nguồn mở .Net và phát triển đa nền tảng! Cam kết xây dựng thư viện công nghệ phát triển .Net hoàn chỉnh! Cung cấp ngôi nhà học tập và giao tiếp cho những người đam mê .Net! .

Cuối cùng, bài viết về dịch thuật: so sánh chi tiết giữa REST và gRPC kết thúc tại đây. Nếu bạn muốn biết thêm về dịch thuật: so sánh chi tiết giữa REST và gRPC, vui lòng tìm kiếm bài viết CFSDN hoặc tiếp tục duyệt qua các bài viết liên quan. hỗ trợ nó trong tương lai blog của tôi! .