Bạn có thể đã nghe những từ như REST được nhắc đến khi nói đến phát triển phần mềm. REST là một kiến trúc API được sử dụng rất phổ biến và các nhà phát triển sử dụng rộng rãi nó để thiết kế các API phần mềm. Giao diện lập trình ứng dụng rất quan trọng đối với bất kỳ ứng dụng phần mềm nào và REST là một trong nhiều kiến trúc được sử dụng cho API.
Ngày nay, kiến trúc g RPC đang trở nên phổ biến và nó cũng tuyên bố sẽ giải quyết một số vấn đề truyền thống liên quan đến các API REST . Nhưng chúng khác nhau ở chỗ nào? Và cái nào bạn nên sử dụng cho ứng dụng của mình? Để biết câu trả lời cho những câu hỏi này, chúng ta cần hiểu thêm về g RPC so với REST và trong những tình huống nào chúng hoạt động tốt hơn. Nhưng trước khi chúng ta đi sâu vào tất cả những điều đó, hãy xem API là gì và chúng mang lại lợi ích gì cho microservice.
API là gì?
Các ứng dụng phần mềm có thể tương tác và giao tiếp với nhau thông qua việc sử dụng các giao diện lập trình ứng dụng - API, hoạt động như các trung gian kỹ thuật. API chịu trách nhiệm gửi yêu cầu của người dùng đến hệ thống, sau đó nhận được phản hồi từ hệ thống.
Hãy tưởng tượng bạn đang đặt mua một chiếc điện thoại trực tuyến. Bạn truy cập một trang web được liên kết với web và nó sẽ gửi thông tin về truy vấn của bạn đến một máy chủ. Sau đó, máy chủ sẽ nhận thông tin, phân tích thông tin đó và sau khi thực hiện các bước cần thiết, sẽ trả lời chúng tôi với các chi tiết hiển thị trên màn hình của chúng tôi. Điều này trở nên khả thi với các API.
API phác thảo cách thực hiện các yêu cầu của khách hàng như vậy, cấu trúc dữ liệu nào sẽ sử dụng và các tiêu chuẩn mà khách hàng phải tuân thủ. Nó cũng mô tả các loại truy vấn mà một chương trình có thể gửi đến một chương trình khác. Cả hai kiểu kiến trúc g RPC và REST đều được sử dụng rộng rãi để thiết kế API.
API và microservice
Các ứng dụng có thể có kiến trúc nguyên khối hoặc kiến trúc microservice. Tất cả các chức năng và mô-đun của phần mềm được chứa trong một đơn vị hoặc cơ sở mã duy nhất trong một ứng dụng nguyên khối. Ngược lại, một ứng dụng microservice bao gồm nhiều đơn vị nhỏ hơn tương tác với nhau qua các giao diện như giao thức HTTP.
Vấn đề chính với phong cách nguyên khối là việc thay đổi, cập nhật và mở rộng hệ thống trở nên khó khăn hơn khi các kỹ sư gắn các chức năng và dịch vụ mới lên trên nền tảng có sẵn. Một thay đổi đối với một khía cạnh của ứng dụng có thể có tác động bất lợi đến các phần khác. Mã của một khối nguyên khối dần trở nên đan xen và khó hiểu sau khi được thu nhỏ, cập nhật và thay đổi nhiều lần nên cần phải thiết kế lại toàn bộ hệ thống.
Vấn đề này được giải quyết với microservice. Thiết kế kiến trúc này chia một nguyên khối thành các thành phần cấu thành của nó, mỗi thành phần sau đó được chạy như một ứng dụng riêng biệt. Mỗi ứng dụng này được gọi là microservice. Sau đó, các dịch vụ siêu nhỏ riêng biệt này kết nối bằng API. Tập hợp các dịch vụ siêu nhỏ được liên kết bởi API này kết hợp với nhau để xây dựng một thiết kế kiến trúc lớn hơn. API cho phép kết nối và giao tiếp giữa từng thành phần được tích hợp vào kiến trúc microservice. Một số cách tiếp cận phổ biến để tạo API là GraphQL, RPC và REST.
RPC là gì?
RPC - Cuộc gọi thủ tục từ xa - là một kiến trúc web cho phép bạn thực thi một dịch vụ trên máy chủ từ xa bằng cách sử dụng biểu mẫu được xác định trước và nhận phản hồi với cùng định dạng. Kiểu máy chủ thực hiện truy vấn, dù là máy chủ cục bộ hay máy chủ từ xa, không được thiết kế RPC xem xét.
Nguồn hình ảnh itrelease.com/Author Junaid Rehman
Chức năng cơ bản của yêu cầu API RPC giống như chức năng của API REST. Các yêu cầu API RPC chỉ định các nguyên tắc tương tác và các kỹ thuật giúp tương tác có thể thực hiện được. Sau đó, người dùng gọi các chức năng này bằng các tham số. Chuỗi URL yêu cầu chứa các tham số được sử dụng để gọi các hoạt động.
Để tạo các yêu cầu API, hệ thống RPC sử dụng cấu trúc máy khách-máy chủ. RPC diễn giải thông tin mà người dùng yêu cầu và truyền nó đến máy chủ. Trong khi thông tin liên lạc nội bộ trong các máy chủ được che giấu, máy chủ sẽ phản hồi cho người dùng. Mô hình RPC cũng cho phép người dùng yêu cầu một dịch vụ theo một cách cụ thể. RPC có lợi thế là hỗ trợ các lệnh gọi thủ tục từ xa trong cả kịch bản phi tập trung và tại chỗ.
REST là gì?
REST - Chuyển giao trạng thái đại diện - đề cập đến kiến trúc máy khách-máy chủ trong đó người dùng có quyền truy cập vào thông tin phụ trợ thông qua giao tiếp JSON hoặc XML . Một API được coi là RESTful nếu:
- Nó có giao diện nhất quán và cung cấp các tài nguyên ứng dụng cụ thể cho các ứng dụng khách API.
- Máy chủ và máy khách hoạt động riêng biệt và độc lập. Máy khách chỉ biết các URI trỏ đến các thành phần của ứng dụng.
- Nó là không quốc tịch. Điều này có nghĩa là chỉ có máy khách lưu bất kỳ thông tin trạng thái nào. Máy chủ sẽ không lưu bất kỳ dữ liệu trạng thái nào về truy vấn máy khách.
- Nội dung ứng dụng do API cung cấp phải được lưu trong bộ nhớ cache.
- Nó có một kiến trúc lớp.
Nó là một ứng dụng của các thiết kế kiến trúc đương đại phụ thuộc vào một số hạn chế để cho phép truyền dữ liệu trong các mạng siêu phương tiện. API web RESTful cần các đối số được mã hóa URL để kết nối với các dịch vụ bằng giao thức HTTP. API REST đã được sử dụng rộng rãi trong thiết kế web hiện đại để tạo ra các API không trạng thái, có thể mở rộng và đáng tin cậy.
Mỗi thành phần kết hợp hệ thống microservice có thể được hiển thị cho người dùng hoặc khách hàng dưới dạng tài sản khi API REST được cung cấp truy cập công khai. Tài nguyên này có thể được truy vấn bằng cách sử dụng các lệnh HTTP GET, POST, PUT và DELETE.
REST hoạt động như thế nào?
REST sử dụng giao thức HTTP làm giao thức liên lạc mặc định khi làm việc với các dịch vụ được chỉ định trong các yêu cầu API. Tài nguyên là một thứ có thể so sánh với một đối tượng trong thiết kế hướng đối tượng. Tài nguyên RESTful có các hành động và thuộc tính, giống như một đối tượng. Nói chung, việc triển khai REST thường ít suy nghĩ hơn về các hành động RESTful và thay vào đó tập trung nhiều hơn vào các thuộc tính của tài nguyên. Các giải pháp RESTful là những giải pháp chỉ sử dụng các thuộc tính để biểu thị tài nguyên RESTful.
Trong API RESTful, người dùng gửi truy vấn tới một URL - Bộ định vị tài nguyên thống nhất, tạo ra phản hồi với tải trọng ở JSON, XML hoặc bất kỳ định dạng dữ liệu được hỗ trợ nào. Tải trọng này đại diện cho tài nguyên mà người dùng muốn. Các yêu cầu phổ biến của khách hàng bao gồm
- Một phương thức HTTP chỉ định những gì sẽ được xử lý trên tài nguyên
- Đường đi của tài nguyên
- Tiêu đề có dữ liệu về truy vấn
- Tải trọng tin nhắn dành riêng cho khách hàng
Trong trường Chấp nhận của tiêu đề, người dùng chỉ định loại dữ liệu mà họ có khả năng nhận. Tiêu đề kiểu nội dung xác định định dạng gửi thư được sử dụng trong nội dung phản hồi được gửi bởi máy chủ API cùng với tải trọng dữ liệu mà nó cung cấp cho người dùng thực hiện truy vấn. Mã trả lời thông báo cho người dùng về trạng thái kết quả của lệnh gọi API cũng được bao gồm trong nội dung phản hồi.
g RPC là gì?
g RPC - Cuộc gọi thủ tục từ xa của Google - là một kiểu con của thiết kế RPC. g RPC là kiến trúc RPC mã nguồn mở, toàn cầu, hiệu suất cao, đảm bảo tính linh hoạt và tốc độ cho kiến trúc vi dịch vụ. Các lời gọi hàm được g RPC sử dụng để đảm bảo sự tương tác của khách hàng trong các vi dịch vụ được tạo bằng nhiều ngôn ngữ lập trình khác nhau.
Kỹ thuật này triển khai các yêu cầu API RPC bằng cách sử dụng tiêu chuẩn HTTP 2.0, nhưng cả máy chủ và lập trình viên API đều không nhận thức được HTTP. Kết quả là, sự phức tạp giảm đi vì không có lý do gì phải lo lắng về cách các nguyên tắc RPC được dịch sang HTTP.
Cuộc gọi thủ tục từ xa của Google tìm cách tăng tốc độ truyền dữ liệu trên các vi dịch vụ. Để cho phép quay lại và gọi từ xa, nó dựa trên chiến lược xác định dịch vụ, thiết lập các phương pháp và chỉ định các biến thích hợp.
Ngoài ra, nó sử dụng IDL - Ngôn ngữ mô tả giao diện - để chỉ định mô hình API RPC, giúp việc xác định các chức năng từ xa trở nên đơn giản hơn. IDL sử dụng Bộ đệm giao thức theo mặc định để xác định giao diện dịch vụ và định dạng của thông báo tải trọng.
g RPC hoạt động như thế nào?
Giao thức HTTP/2, truyền trực tuyến và bộ đệm giao thức hoặc protobufs được g RPC API sử dụng để truyền thông báo. Một tiêu chuẩn tuần tự hóa được gọi là protobuf cho phép tạo tự động các thư viện người dùng và xây dựng các dịch vụ siêu nhỏ một cách đơn giản. Trong các tệp proto, các nhà thiết kế API mô tả các hoạt động và thông báo được gửi giữa các máy chủ và máy khách.
Trình biên dịch protoc tải các tệp và tạo phần mềm người dùng và máy chủ để giao tiếp với các dịch vụ từ xa. So với các định dạng XML hoặc JSON, các thông báo được mã hóa bằng bộ đệm giao thức nhỏ hơn đáng kể, khiến việc xử lý ít tốn CPU hơn.
Ngoài ra, bằng cách sử dụng API HTTP/2, g RPC mang lại nhiều cải tiến khác nhau cho thiết kế RPC. Giao thức bổ sung một lớp định dạng nhị phân để chia các gói thành các thông điệp nhỏ hơn, có khung nhị phân, khiến chúng có thể vận chuyển được và có kích thước nhỏ. Việc thực hiện nhiều cuộc gọi bên trong một kênh duy nhất có thể thực hiện được nhờ sự hỗ trợ của HTTP/2 cho nhiều truy vấn đồng thời với kiến trúc giao tiếp hai chiều.
Giao thức truyền tải HTTP/2 hỗ trợ nhiều luồng đồng thời, nhưng API g RPC mở rộng chức năng này qua các kênh. Mỗi kênh có thể chứa một số luồng chạy đồng thời thông qua nhiều kết nối đồng thời. Các kênh cung cấp một phương thức đơn giản để kết nối với máy chủ API tại một địa chỉ và cổng nhất định. Sơ khai khách hàng cũng có thể được thực hiện thông qua các kênh.
g RPC vs REST: so sánh
Google đã tạo g RPC dưới dạng một biến thể RPC để giải quyết một số hạn chế của các kiểu kiến trúc API hiện có. Nó giải quyết một số vấn đề liên quan đến API REST, nhưng API g RPC gặp phải một số vấn đề nhất định do đây là công nghệ mới hơn. Có nhiều trường hợp sử dụng mà API REST có thể phù hợp hơn với ứng dụng của bạn. Bạn có thể quyết định API nào trong số những API này có thể hoạt động tốt hơn với phần mềm của mình khi bạn biết sự khác biệt giữa hai API này.
HTTP 1.1 so với HTTP 2
Cách tiếp cận yêu cầu-trả lời được sử dụng bởi các API REST chủ yếu dựa trên HTTP 1.1. Điều này có nghĩa là mô hình phải xử lý từng truy vấn riêng lẻ nếu một vi dịch vụ nhận được nhiều truy vấn từ nhiều máy khách, điều này sẽ kéo toàn bộ hệ thống xuống. API REST có thể được phát triển trên HTTP 2, nhưng vì kiến trúc giao tiếp vẫn là phản hồi theo yêu cầu nên chúng không thể sử dụng đầy đủ các lợi ích của HTTP 2, bao gồm khả năng tương thích hai chiều và tương tác truyền trực tuyến.
g RPC không gặp phải thử thách này. Nó tuân thủ mô hình kết nối phản hồi giữa máy khách và dựa trên HTTP 2. g RPC có thể chấp nhận nhiều truy vấn từ nhiều máy khách khác nhau và xử lý các yêu cầu đó cùng một lúc thông qua thông tin truyền trực tuyến. Những trường hợp này cho phép giao tiếp hai chiều với tương tác trực tuyến. Ngoài ra, g RPC hỗ trợ các tương tác đơn nguyên giống như các tương tác được tạo bởi HTTP 1.1.
g RPC có thể quản lý:
- tương tác đơn phương
Nếu một khách hàng đưa ra một yêu cầu duy nhất, nhưng chỉ một câu trả lời được đưa ra. - Máy chủ phát trực tuyến
Nó được gọi là phát trực tuyến máy chủ bất cứ khi nào máy chủ trả lời truy vấn của khách hàng bằng một luồng thông báo. Máy chủ cũng gửi một thông báo trạng thái để kết thúc quy trình sau khi cung cấp tất cả dữ liệu. - khách hàng trực tuyến
Điều này xảy ra khi máy khách gửi một chuỗi tin nhắn và máy chủ phản hồi bằng một tin nhắn. - truyền phát hai chiều
Điều này cho phép truyền dữ liệu theo cả hai cách vì các kênh máy chủ và máy khách độc lập với nhau.
hỗ trợ trình duyệt
Vì hầu hết tương tác API web diễn ra trực tuyến, hỗ trợ trình duyệt là yếu tố chính cần cân nhắc trong cuộc tranh luận g RPC so với REST. Hỗ trợ trình duyệt có thể là một trong những lợi ích chính của API REST so với g RPC. Tất cả các trình duyệt đều cung cấp khả năng API REST đầy đủ và hỗ trợ trình duyệt. Tuy nhiên, chức năng cho g RPC trong trình duyệt vẫn còn tương đối hạn chế. Thật không may, quá trình chuyển đổi qua HTTP 1.1 và HTTP 2 cần gRPC-web cũng như lớp proxy. Do đó, các API g RPC có xu hướng chủ yếu được sử dụng cho các hệ thống nội bộ hoặc riêng tư, chẳng hạn như trong các ứng dụng API được sử dụng cho thông tin phụ trợ và chức năng của các tổ chức cụ thể.
Luồng ghép kênh được sử dụng với giao thức HTTP/2. Do đó, nhiều khách hàng có thể gửi truy vấn song song mà không cần mở phiên TCP mới cho từng truy vấn. Ngoài ra, máy chủ có thể sử dụng liên kết hiện có để gửi tin nhắn cho khách hàng.
Mô hình chuyển trạng thái đại diện có hỗ trợ trình duyệt rộng rãi vì nó tích hợp HTTP 1.1. HTTP 1.1, mà REST cho phép, sử dụng phương pháp bắt tay TCP cho mỗi truy vấn. Các API REST thường gặp vấn đề về độ trễ do quá trình bắt tay mất nhiều thời gian.
Cấu trúc dữ liệu tải trọng
Nếu chúng ta đang xem xét cấu trúc dữ liệu tải trọng trong khi xem xét g RPC so với REST, thì các API g RPC sẽ tuần tự hóa dữ liệu tải trọng bằng cách sử dụng Bộ đệm giao thức theo thiết kế. Phương pháp này nhẹ hơn vì nó làm cho các thông báo nhỏ hơn và cho phép cấu trúc được nén ở mức độ cao. Bộ đệm giao thức ở định dạng nhị phân; do đó, để trao đổi dữ liệu, nó tuần tự hóa và giải tuần tự hóa thông tin. Protobuf có thể tự động dịch các tin nhắn được viết nhiều sang ngôn ngữ lập trình máy khách và máy chủ.
Tuy nhiên, REST chủ yếu sử dụng các biểu mẫu JSON hoặc XML để gửi và nhận thông tin. JSON là định dạng được sử dụng rộng rãi nhất vì khả năng thích ứng và khả năng giao tiếp dữ liệu động của nó mà không cần tuân theo một cấu trúc chính xác, mặc dù nó không yêu cầu bất kỳ điều gì. Chất lượng mà con người có thể đọc được của JSON, điều mà Protobuf chưa thể sánh được, là một lợi thế quan trọng khác.
Tuy nhiên, JSON không nhanh hoặc nhẹ khi nó liên quan đến truyền dữ liệu. Điều này là do yêu cầu JSON phải được tuần tự hóa và dịch sang ngôn ngữ lập trình được sử dụng trên cả máy chủ và máy khách khi sử dụng REST. Đây là một bước bổ sung trong quy trình truyền dữ liệu, có thể gây hại cho hiệu quả và tăng khả năng mắc lỗi.
Tạo mã
Kể từ đó, các kỹ sư phải sử dụng các công cụ của bên thứ ba như Postman để tạo mã cho các truy vấn API và không giống như g RPC, API REST thiếu các phương tiện tạo mã tích hợp. Trái ngược với điều này, g RPC cung cấp các tính năng tạo mã gốc nhờ trình biên dịch protoc của nó, hỗ trợ nhiều ngôn ngữ lập trình. Việc tạo mã đặc biệt thuận lợi cho các vi dịch vụ kết hợp nhiều dịch vụ được tạo trên nhiều nền tảng và ngôn ngữ. Nhìn chung, việc tạo mã tích hợp của nó giúp việc xây dựng bộ công cụ phát triển phần mềm - SDK - trở nên dễ dàng hơn.
Mặt khác, API REST không cung cấp các tính năng tạo mã gốc. Bạn phải sử dụng chương trình của bên thứ ba để tạo mã cho lệnh gọi API bằng một số ngôn ngữ. Mặc dù nó không rắc rối, nhưng điều quan trọng cần lưu ý là g RPC không dựa vào bất kỳ dịch vụ nào khác để tạo mã.
Khi nào nên sử dụng API REST
Khi so sánh g RPC với REST, API được sử dụng rộng rãi và phổ biến nhất để tích hợp cơ sở hạ tầng được xây dựng trên vi dịch vụ là API REST. API REST có thể sẽ tiếp tục là tùy chọn mặc định cho kết nối ứng dụng trong một thời gian rất dài, bất kể bạn đang tạo mạng nội bộ hay nền tảng mở mở nội dung của nó cho phần còn lại của thế giới. API REST cũng hoàn hảo cho các hệ thống yêu cầu lặp lại nhanh chóng và các tiêu chuẩn giao thức HTTP.
API REST có thể là lựa chọn đầu tiên của bạn để phát triển dịch vụ web, vi dịch vụ và giao diện ứng dụng vì các công nghệ của bên thứ ba đều hỗ trợ chúng. Không giống như g RPC, nó có hỗ trợ nhiều trình duyệt và không giới hạn ở các hệ thống riêng tư. Điều này có thể làm cho API REST trở nên rất hữu ích trong nhiều ngữ cảnh.
Việc học REST cũng dễ dàng hơn vì nó có rất nhiều tài liệu API có sẵn trên internet. Đường cong học tập đơn giản hơn này rất quan trọng nếu bạn đang gặp khó khăn về thời gian. Bạn có thể tiết kiệm rất nhiều thời gian nghiên cứu và học hỏi và bắt tay vào thực hiện ngay lập tức. API RESTful cũng dễ dàng tích hợp vào các ứng dụng hơn. Họ cũng cung cấp khả năng mở rộng tốt hơn. Nếu bạn muốn sớm mở rộng ứng dụng của mình, có thể tốt hơn là sử dụng API REST. Việc thiếu trạng thái và tính bảo mật có thể gây ra vấn đề với việc chuyển trạng thái đại diện trong một số ứng dụng nhất định. Nếu ứng dụng của bạn có tùy chọn thanh toán, g RPC có thể là một tùy chọn tốt hơn.
Khi nào nên sử dụng API g RPC
Trong cả g RPC và REST, phần lớn các công cụ của bên thứ ba vẫn không cung cấp chức năng tích hợp để tuân thủ g RPC. Do đó, API g RPC chủ yếu được sử dụng để tạo các hệ thống hoặc cấu trúc nội bộ mà người dùng bên ngoài không thể truy cập được. Với tiêu chuẩn đó, các tình huống sau đây có thể sử dụng API g RPC:
- Kết nối microservice
g RPC đặc biệt hữu ích cho việc liên kết các kiến trúc được tạo thành từ các vi dịch vụ nhẹ, trong đó tính hiệu quả của việc gửi thông báo là rất quan trọng do độ trễ thấp và giao tiếp băng thông nhanh.
- Hệ thống đa ngôn ngữ
g RPC vượt trội trong việc xử lý thông tin liên lạc trong ngữ cảnh đa ngôn ngữ nhờ khả năng tạo mã gốc cho nhiều loại ngôn ngữ lập trình.
- Truyền phát thời gian thực
Nếu giao tiếp thời gian thực là cần thiết, hệ thống của bạn có thể truyền và nhận dữ liệu trong thời gian thực mà không cần phải đợi tương tác phản hồi giữa máy khách và máy khách đơn nhất nhờ khả năng xử lý truyền phát hai chiều của gRPC.
- Mạng công suất thấp và băng thông thấp
Các mạng như vậy có thể được hưởng lợi từ việc gRPC sử dụng các phiên Protobuf được tuần tự hóa vì chúng cung cấp khả năng giao tiếp nhẹ nhàng, hiệu quả được cải thiện và sự nhanh chóng. Ví dụ: một mạng sẽ thu được lợi nhuận từ API g RPC là Internet of Things.
AppMaster trợ giúp như thế nào?
Lập trình đã thay đổi rất nhiều trong những thập kỷ gần đây, với các công nghệ và khuôn khổ mới giúp nhiệm vụ của các nhà phát triển trở nên dễ dàng hơn. Việc tạo No-code cần đưa điều này lên cấp độ tiếp theo. Mọi người không cần phải trải qua quá trình học tập khó khăn và có thể phát triển ứng dụng nhanh hơn với các nền tảng no-code như AppMaster.
AppMaster giúp bạn tạo mã nguồn từ đầu theo nhu cầu cụ thể của ứng dụng của bạn. Mã được tạo sẽ thuộc về bạn và bạn có thể sửa đổi nó theo nhu cầu của mình. Bạn có thể tạo các mô-đun khác nhau mà ứng dụng của bạn cần với AppMaster. Điều này ít tốn kém và tốn thời gian hơn nhiều so với việc yêu cầu toàn bộ nhóm phát triển làm điều tương tự.
Các nhà phát triển có thể gửi truy vấn giữa kiến trúc vi dịch vụ phụ trợ bằng giao thức g RPC bằng nền tảng tạo no-code của AppMaster. Chúng tôi sẽ thêm API vào cả quá trình phát triển dịch vụ web g RPC cũng như ứng dụng di động g RPC vào năm sau để tăng cường hỗ trợ g RPC.
Sự kết luận
Chuyển trạng thái đại diện là cách tiếp cận phù hợp khi phát triển API trong quá khứ. Nhưng giữa g RPC vs REST, API g RPC đang dần trở nên phổ biến hơn. Mặc dù có nhiều tính năng khác nhau khiến nó trở nên nổi bật, nhưng một số vấn đề, chẳng hạn như thiếu hỗ trợ trình duyệt và tài liệu API, khiến việc sử dụng nó ở mọi nơi trở nên khó khăn. Tuy nhiên, với những tiến bộ công nghệ và sự phát triển của cộng đồng, chúng ta có thể hy vọng rằng g RPC sẽ vượt qua những thách thức ngày nay.
Cuối cùng, việc chọn giữa REST hoặc g RPC hoặc thậm chí bất kỳ phương pháp API nào khác như GraphQL hoặc SOAP , tùy thuộc vào nhu cầu cụ thể của dự án của bạn. Một số ứng dụng có thể cần những lợi ích mà g RPC mang lại, trong khi những ứng dụng khác có thể yêu cầu chức năng cơ bản mà REST cung cấp. Bạn cần đánh giá các chức năng của ứng dụng và các trường hợp sử dụng để chọn giữa hai công nghệ có khả năng này.
