Связь Между C# И C#: Rest, Grpc И Все, Что Между Ними.

Существует множество способов взаимодействия между клиентом C# и сервером C#.

Некоторые из них надежны, другие нет. Некоторые очень быстрые, другие нет. Важно знать различные варианты, чтобы вы могли решить, что лучше для вас.

В этой статье будут рассмотрены наиболее популярные сегодня технологии и почему они так широко используются.

Мы поговорим об REST, gRPC и обо всем, что между ними.



Оптимальный сценарий

Давайте посмотрим, как бы мы хотели, чтобы наша связь клиент-сервер выглядела в реальном мире.

Я представляю себе что-то вроде этого:

  
  
  
  
  
  
  
   

// 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. Когда я нажимаю сервер И .

Я хочу, чтобы Visual Studio показывала все контроллеры.

И когда я нажимаю КалькуляторКонтроллер И .

, я хочу увидеть все методы действий.

Мне также нужна максимальная производительность, очень низкие сетевые нагрузки и двунаправленная передача данных.

И мне нужна надежная система, которая отлично поддерживает управление версиями, чтобы я мог без проблем развертывать новые версии клиентов и новые версии серверов.

Это слишком много? Обратите внимание, что здесь я говорю об API. лицо без гражданства .

Это эквивалентно проекту C#, в котором есть только два типа классов:

  • Статические классы только со статическими методами.

  • Классы POCO, которые не имеют ничего, кроме полей и свойств, тип которых является примитивом или другим классом POCO.
Наличие состояния в API усложняет работу, и это корень всех зол.

Итак, ради этой статьи давайте сделаем вещи красивыми и безгражданскими.



Традиционный подход REST

ОТДЫХ API появился в начале 2000-х годов и покорил Интернет. Сегодня это, безусловно, самый популярный способ создания веб-сервисов.

ОТДЫХ определяет фиксированный набор операций ПОЛУЧАТЬ , ПОЧТА , ПОМЕЩАТЬ И УДАЛИТЬ для запросов от клиента к серверу.

На каждый запрос мы получаем ответ, содержащий полезную нагрузку (обычно JSON).

Запросы включают параметры в самом запросе или в виде полезных данных (обычно JSON), если это запрос POST или PUT. Есть стандарт RESTful API который определяет следующие правила (которые вам на самом деле не нужны):

  • GET используется для получения ресурса
  • PUT используется для изменения состояния ресурса.

  • POST используется для создания ресурса
  • DELETE используется для удаления ресурса.

Если вы еще не знакомы с REST, приведенное выше объяснение, вероятно, не поможет, поэтому вот пример.

.

NET имеет встроенную поддержку REST. Фактически, веб-API ASP.NET по умолчанию является веб-службой REST. Вот как выглядит типичный клиент и сервер ASP.NET: На сервере:

[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 чертовски удобен, но не соответствует оптимальному сценарию.

Итак, давайте посмотрим, сможем ли мы сделать это лучше.



Переоборудование

Переоборудование не является альтернативой REST. Вместо этого он построен на основе REST и позволяет нам вызывать конечные точки сервера, как если бы это был простой метод. Это достигается за счет разделения интерфейса между клиентом и сервером.

На стороне сервера ваш контроллер будет реализовывать интерфейс:

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. Это становится намного ближе к оптимальному сценарию.

Теперь у нас есть IntelliSense и безопасный контракт между клиентом и сервером.

Но есть другой вариант, который в некоторых отношениях даже лучше.



Сваггер

Как и ReFit, Swagger также построен на основе REST. OpenAPI , или Сваггер , — это спецификация REST API. Он описывает веб-службу REST с простыми файлами JSON. Эти файлы представляют собой схему API веб-сервиса.

К ним относятся:

  • Все пути (URL) в API.
  • Ожидаемые операции (GET, POST,.

    ) для каждого пути.

    Каждый путь может обрабатывать разные операции.

    Например, тот же путь mystore.com/Продукт может принимать операцию POST, добавляющую товар, и операцию GET, возвращающую товар.

  • Ожидаемые параметры для каждого пути и операции.

  • Ожидаемые ответы для каждого пути.

  • Типы каждого параметра и объекта ответа.

Этот файл JSON по сути представляет собой контракт между клиентами и сервером.

Вот пример файла swagger, описывающего веб-сервис под названием Сваггер зоомагазин (Я удалил некоторые части для ясности): Схема JSON

{ "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" } } }, .



Давайте посмотрим на последствия этого.

С помощью файла JSON, подобного приведенному выше, вы потенциально можете создать клиент C# с полной поддержкой IntelliSense. Ведь вы знаете все пути, операции, какие параметры они ожидают, какие типы параметров, какие ответы.

Есть несколько инструментов, которые делают именно это.

На стороне сервера вы можете использовать Свашбакл.

AspNetCore чтобы добавить Swagger в ASP.NET и сгенерировать указанные файлы JSON. На стороне клиента вы можете использовать чванство-кодеген И Авторест для обработки этих файлов JSON и создания клиента.

Давайте посмотрим пример того, как это сделать:

Добавление Swagger на ваш сервер ASP.NET

Начните с добавления пакета NuGet. Свашбакл.

AspNetCore .

В Конфигуресервис , зарегистрируйте генератор Swagger:

services.AddSwaggerGen(options =>

Теги: #C++ #.

NET #grpc #rest #ASP.NET #ASP #ASP #коммуникация #клиент-серверные приложения

Вместе с данным постом часто просматривают: