本文來自：https://michaelscodingspot.com/rest-vs-grpc-for-asp-net/

淺議C#客戶端和服務(wù)端通信的幾種方法：Rest和GRPC

在C＃客戶端和C＃服務(wù)器之間進行通信的方法有很多。一些功能強大，而其他功能則不是很多。有些非常快，有些則不是。知道不同的選擇很重要，這樣您才能決定最適合自己的選擇。

本文將介紹當今最流行的技術(shù)，以及為何如此廣泛地使用它們。我們將討論REST，gRPC及其兩者之間的所有內(nèi)容。

最佳方案

讓我們考慮一下我們希望如何在最佳環(huán)境中使客戶端與服務(wù)器之間的通信看起來像。我在想像這樣的東西：

// on client side public void Foo() {var server = new MyServer(new Uri("https://www.myserver.com/");)int sum = server.Calculator.SumNumbers(12,13); } // on server side class CalculatorController : Controller{public int SumNumbers(int a, int b){return a + b;} }

我當然想要完整的Intellisense。當我單擊server并.?希望Visual Studio顯示所有控制器時。當我單擊CalculatorController和時.，我想查看所有操作。我還想要一流的性能，很少的網(wǎng)絡(luò)負載和雙向通信。而且我想要一個能夠完美處理版本控制的強大系統(tǒng)，這樣我就可以毫不費力地部署新的客戶端版本和新的服務(wù)器版本。

要求太多嗎？

請注意，我在這里談?wù)摰氖?strong>無狀態(tài)API。這等效于C＃項目，其中只有兩種類型的類：

?靜態(tài)類，只有靜態(tài)方法。?POCO類^[1]僅具有類型為基本類型或其他POCO類的字段和屬性。

在API中使用狀態(tài)會帶來復(fù)雜性，而這正是萬惡之源。因此，為了本文的方便，讓我們保持美好和無狀態(tài)。

傳統(tǒng)REST

REST API出現(xiàn)在2000年代初期，席卷了整個互聯(lián)網(wǎng)。到目前為止，它是創(chuàng)建Web服務(wù)的最流行的方法。

REST為客戶端到服務(wù)器的請求定義了一組固定的操作GET，POST，PUT和DELETE。每個請求都將通過包含有效負載（通常為JSON）的響應(yīng)來回答。請求包含在查詢本身中的參數(shù)，或者在它是POST請求時包含為有效負載（通常為JSON）的參數(shù)。

有一個稱為RESTful API的標準，它定義了以下規(guī)則（您實際上不必使用它）：

?GET用于檢索資源?PUT用于更改資源狀態(tài)?POST用于創(chuàng)建資源?DELETE用于刪除資源

如果您到目前為止還不熟悉REST，則上面的解釋可能不會減少它，因此這里有一個示例。在.NET中，內(nèi)置了對REST的支持。實際上，默認情況下，ASP.NET Web API被構(gòu)建為REST Web服務(wù)。這是典型的客戶端和ASP.NET服務(wù)器的外觀：

在服務(wù)器中：

[Route("People")] public class PeopleController : Controller {[HttpGet]public Person GetPersonById(int id){Person person = _db.GetPerson(id);return person;//Automatically serialized to JSON} }

在客戶中：

var client = new HttpClient(); string resultJson = await client.GetStringAsync("https://www.myserver.com/People/GetPersonById?id=123"); Person person = JsonConvert.DeserializeObject<Person>(resultJson);

REST非常方便，但是并沒有達到最佳方案。因此，讓我們看看是否可以做得更好。

ReFit

ReFit不能替代REST。相反，它建立在REST之上，并允許我們像調(diào)用簡單方法一樣調(diào)用服務(wù)器端點。這是通過在客戶端和服務(wù)器之間共享接口來實現(xiàn)的。在服務(wù)器端，您的控制器將實現(xiàn)一個接口：

public interface IMyEmployeeApi {[Get("/employee/{id}")]Task<Employee> GetEmployee(string id); }

然后，在客戶端，您需要包括相同的接口并使用以下代碼：

var api = RestService.For<IMyEmployeeApi>("https://www.myserver.com"); var employee = await api.GetEmployee("abc");

就這么簡單。除了幾個NuGet軟件包外，無需運行困難的自動化程序或使用任何第三方工具。

這更接近最佳方案。現(xiàn)在，我們有了IntelliSense，并且客戶端和服務(wù)器之間的合同很牢固。但是還有另一種選擇，在某些方面甚至更好。

昂首闊步

像ReFit一樣，Swagger也建立在REST之上。OpenAPI^[2]或Swagger是REST API的規(guī)范。它描述了具有簡單JSON文件的REST Web服務(wù)。這些文件是Web服務(wù)的API架構(gòu)。它們包括：

?API中的所有路徑（URL）。?每個路徑的預(yù)期操作（GET，POST等）。每個路徑可以處理不同的操作。例如，單個路徑https://mystore.com/Product可能接受添加產(chǎn)品的POST操作和返回產(chǎn)品的GET操作。?每個路徑和操作的預(yù)期參數(shù)。?每個路徑的預(yù)期響應(yīng)。?每個參數(shù)和響應(yīng)對象的類型。

該JSON文件實質(zhì)上是客戶端和服務(wù)器之間的合同。這是一個描述一個稱為Swagger Petstore^[3]的Web服務(wù)的swagger文件的示例（為清楚起見，我刪除了一些部分）：

{ "swagger":"2.0","info":{ "version":"1.0.0","title":"Swagger Petstore","description":"A sample API that uses a petstore as an example to demonstrate features in the swagger-2.0 specification",},"host":"petstore.swagger.io","basePath":"/api","schemes":[ "http"],"consumes":[ "application/json"],"produces":[ "application/json"],"paths":{ "/pets":{ "get":{ "description":"Returns all pets from the system that the user has access to","operationId":"findPets","produces":[ "application/json","application/xml",],"parameters":[ { "name":"tags","in":"query","description":"tags to filter by","required":false,"type":"array","items":{ "type":"string"},"collectionFormat":"csv"},{ "name":"limit","in":"query","description":"maximum number of results to return","required":false,"type":"integer","format":"int32"}],"responses":{ "200":{ "description":"pet response","schema":{ "type":"array","items":{ "$ref":"#/definitions/Pet"}}}, ...

讓我們考慮一下這個結(jié)果。使用上面的JSON文件，您可以潛在地創(chuàng)建具有完整IntelliSense的C＃客戶端。畢竟，您知道所有路徑，操作，它們期望的參數(shù)，什么參數(shù)類型，什么是響應(yīng)等等。

有幾種工具可以做到這一點。對于服務(wù)器端，可以使用Swashbuckle.AspNetCore^[4]將Swagger添加到ASP.NET中并生成所述JSON文件。對于客戶端，您可以使用swagger-codegen^[5]和AutoRest^[6]來使用這些JSON文件并生成客戶端。讓我們看一個如何做到這一點的例子：

將Swagger添加到ASP.NET服務(wù)器

首先添加NuGet包Swashbuckle.AspNetCore^[7]。在中ConfigureServices，注冊Swagger生成器：

services.AddSwaggerGen(options => options.SwaggerDoc("v1", new OpenApiInfo {Title = "My Web API", Version = "v1"}));

在添加Configure方法中Startup.cs：

app.UseSwagger();

最后，控制器內(nèi)部的動作應(yīng)使用[HttpXXX]和[FromXXX]屬性修飾：

[HttpPost] public async Task AddEmployee([FromBody]Employee employee) {//... }[HttpGet] public async Task<Employee> Employee([FromQuery]string id) {//... }

就像服務(wù)器端一樣簡單。運行項目時，swagger.json將生成一個文件，可用于生成客戶端。

使用AutoRest從Swagger生成客戶端

要開始使用AutoRest^[8]，與安裝NPM^[9]：npm install -g autorest。安裝后，您將需要使用AutoRest的命令行界面從該swagger.json文件生成C＃客戶端。這是一個例子：

autorest --input-file="./swagger.json" --output-folder="GeneratedClient" --namespace="MyClient" --override-client-name="MyClient" --csharp

這將產(chǎn)生一個GeneratedClient包含生成的C＃文件的文件夾。請注意，名稱空間和客戶端名稱被覆蓋。從這里，將此文件夾添加到Visual Studio中的客戶端項目。

您需要安裝Microsoft.Rest.ClientRuntimeNuGet軟件包，因為生成的代碼取決于該軟件包。安裝后，您可以像使用常規(guī)C＃類一樣使用API：

var client = new MyClient(); Employee employee = client.Employee(id: "abc");

您可以在AutoRest的文檔中^[10]閱讀一些細微之處。而且您需要使該過程自動化，因此我建議閱讀Patrik Svensson的教程，^[11]以獲得一些好的建議以及Peter Jausovec的這篇文章^[12]。

Swagger的問題是JSON文件是在運行時創(chuàng)建的，因此這使得在CI / CD流程中實現(xiàn)自動化有點困難。

傳統(tǒng)REST vs Swagger vs ReFit

進行選擇時，請注意以下幾點。

?如果您有一個非常簡單的私有REST API，則也許不必理會客戶端生成和共享接口。小任務(wù)并不能證明付出額外的努力是合理的。?Swagger支持多種語言，而ReFit僅支持.NET。Swagger還是許多工具，測試，自動化和UI工具的基礎(chǔ)。如果您要創(chuàng)建一個大型的公共API，它將可能是最佳選擇。?Swagger比ReFit復(fù)雜得多。使用ReFit，只需在服務(wù)器和客戶端項目中添加一個接口即可。另一方面，使用ReFit，您必須為每個控制器創(chuàng)建新的接口，而Swagger會自動進行處理。

但是在決定任何事情之前，請檢查與REST無關(guān)的第四個選項。

gRPC

gRPC^[13]（gRPC遠程過程調(diào)用）是Google開發(fā)的開源遠程過程調(diào)用系統(tǒng)。它有點像REST，它提供了一種將請求從客戶端發(fā)送到服務(wù)器的方式。但這在許多方面都不同，這是相同點和不同點：

?像REST一樣，gRPC與語言無關(guān)。有適用于所有流行語言的工具，包括C＃。?gRPC是契約的基礎(chǔ)，并使用.proto文件來定義契約。這有點類似于Swaggerswagger.json和ReFit的共享界面。可以從那些文件中生成任何編程語言的客戶端。?gRPC使用協(xié)議緩沖區(qū)（Protobuf）^[14]二進制序列化。這與REST（通常序列化為JSON或XML）不同。二進制序列化較小，因此更快。?gRPC用于使用HTTP / 2協(xié)議創(chuàng)建持久連接。該協(xié)議更簡單，更緊湊。REST使用HTTP 1.x協(xié)議（通常為HTTP 1.1）。?HTTP 1.1要求每個請求都進行TCP握手，而HTTP / 2則保持連接打開。?HTTP / 2連接使用多路復(fù)用流。這意味著單個TCP連接可以支持許多流。這些流可以并行執(zhí)行，而不必像HTTP 1.1中那樣互相等待。?gRPC允許雙向流。

有兩種使用gRPC的方法。對于.NET Core 3.0，有一個完全托管的庫，稱為.NET的gRPC^[15]。對于其中的任何內(nèi)容，您都可以使用gRPC C＃^[16]，它是使用本機代碼構(gòu)建的。這并不意味著適用于.NET的gRPC可以替代gRPC C＃。讓我們來看一個用于.NET的更新gRPC的示例。

.NET的gRPC的服務(wù)器端

這不是教程，而是更多有關(guān)預(yù)期內(nèi)容的一般性想法。這是示例控制器在gRPC中的外觀：

public class GreeterService : Greeter.GreeterBase {public override Task<HelloReply> SayHello(HelloRequest request,ServerCallContext context){_logger.LogInformation("Saying hello to {Name}", request.Name);return Task.FromResult(new HelloReply {Message = "Hello " + request.Name});} }

您需要添加以下的Configure在Startup.cs：

app.UseEndpoints(endpoints => {endpoints.MapGrpcService<GreeterService>(); });

API在.proto文件中描述，該文件是項目的一部分：

syntax = "proto3";service Greeter {rpc SayHello (HelloRequest) returns (HelloReply); }message HelloRequest {string name = 1; }message HelloReply {string message = 1; }

此.proto文件添加到.csproj：

<ItemGroup><Protobuf Include="Protos\greet.proto" /> </ItemGroup>

.NET的gRPC客戶端

客戶端是從.proto文件生成的。代碼本身非常簡單：

var channel = GrpcChannel.ForAddress("https://localhost:5001"); var client = new Greeter.GreeterClient(channel);var response = await client.SayHello(new HelloRequest { Name = "World" });Console.WriteLine(response.Message);

gRPC與REST

gRPC聽起來不錯。它在框架下更快，更簡單。那么，我們都應(yīng)該從REST變?yōu)間RPC嗎？答案是，這取決于你的應(yīng)用場景。

以下是一些注意事項：

從我的印象來看，使用gRPC和ASP.NET仍然不是很好。借助對REST的成熟支持，您會變得更好。就基于契約的通信而言，這很不錯，除了在REST中有我們已經(jīng)討論過的類似替代方案：Swagger和ReFit。

最大的優(yōu)勢是性能。根據(jù)這些基準^[17]，在大多數(shù)情況下，gRPC更快。特別是對于大型有效載荷，Protobuf序列化確實有所作為。這意味著對于高負載服務(wù)器而言，這是一個巨大的優(yōu)勢。

在大型ASP.NET應(yīng)用程序中從REST過渡到gRPC將非常困難。但是，如果您具有基于微服務(wù)的體系結(jié)構(gòu)，那么逐步完成此過渡就變得容易得多。

其他溝通方式

還有其他一些我完全沒有提及的通信方式，但是值得一提的是：

?GraphQL^[18]是Facebook開發(fā)的API的查詢語言。它允許客戶端從服務(wù)器確切地要求它需要的數(shù)據(jù)。這樣，您可以在服務(wù)器上僅創(chuàng)建一個端點，該端點將非常靈活，并且僅返回客戶端所需的數(shù)據(jù)。近年來，GraphQL變得非常流行。?SignalR^[19]是一項允許服務(wù)器與客戶端之間進行實時雙向通信的技術(shù)。SignalR不僅允許客戶端始終向服務(wù)器發(fā)送請求，還允許服務(wù)器向客戶端發(fā)送推送通知。這樣可以查看Web應(yīng)用程序中的實時更新。SignalR在ASP.NET中非常流行。?TcpClient^[20]和TcpListener^[21]（在中System.Net.Sockets）提供基于TCP的低級連接。基本上，您將建立連接并傳輸字節(jié)數(shù)組。對于大型應(yīng)用程序而言，它不是理想的選擇，在大型應(yīng)用程序中，您可以使用ASP.NET的控制器和操作在大型API中進行訂購。?UdpClient^[22]提供了一種通過UDP協(xié)議進行通信的方法。TCP建立連接，然后發(fā)送數(shù)據(jù)，而UDP僅發(fā)送數(shù)據(jù)。TCP確保數(shù)據(jù)中沒有錯誤，而UDP沒有。UDP可以更有效地快速傳輸數(shù)據(jù)，您不必擔(dān)心它是否可靠且沒有錯誤。一些示例是：視頻流，實時廣播和IP語音（VoIP）。?WCF^[23]是一種較舊的技術(shù)，主要在進程之間使用基于SOAP的通信。這是一個龐大的框架，我要說的是它已不再受REST和JSON負載的歡迎。

References

[1]?POCO類:?https://www.c-sharpcorner.com/UploadFile/5d065a/poco-classes-in-entity-framework/
[2]?OpenAPI:?https://swagger.io/specification/
[3]?Swagger Petstore:?https://bfanger.nl/swagger-explained/#operationObject
[4]?Swashbuckle.AspNetCore:?https://github.com/domaindrivendev/Swashbuckle.AspNetCore
[5]?swagger-codegen:?https://github.com/swagger-api/swagger-codegen
[6]?AutoRest:?https://azure.github.io/autorest/
[7]?Swashbuckle.AspNetCore:?https://www.nuget.org/packages/Swashbuckle.AspNetCore
[8]?AutoRest:?https://github.com/Azure/autorest
[9]?NPM:?https://www.w3schools.com/nodejs/nodejs_npm.asp
[10]?文檔中:?https://azure.github.io/autorest/client/ops.html
[11]?教程，:?https://www.patriksvensson.se/2018/10/generating-api-clients-using-autorest
[12]?文章:?https://medium.com/@pjausovec/creating-c-client-library-for-web-api-projects-be132c831f9c
[13]?gRPC:?https://grpc.io/
[14]?協(xié)議緩沖區(qū)（Protobuf）:?https://en.wikipedia.org/wiki/Protocol_Buffers
[15]?.NET的gRPC:?https://github.com/grpc/grpc-dotnet
[16]?gRPC C＃:?https://github.com/grpc/grpc/tree/master/src/csharp
[17]?根據(jù)這些基準:?https://www.yonego.com/nl/why-milliseconds-matter/#gref
[18]?GraphQL:?https://graphql.org/
[19]?SignalR:?https://github.com/SignalR/SignalR
[20]?TcpClient:?https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.tcpclient?view=netframework-4.8
[21]?TcpListener:?https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.tcplistener?view=netframework-4.8
[22]?UdpClient:?https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.udpclient?view=netframework-4.8
[23]?WCF:?https://docs.microsoft.com/en-us/dotnet/framework/wcf/whats-wcf

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的浅议C#客户端和服务端通信的几种方法：Rest和GRPC和其他的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。