public class Verifyabc : IdentityBase  
{  
   public override string PrjName { get; set; } = «abc»; //Название проекта  
  
  public override Verifymode attestation(string Loginname, string Password)  
  {  
      Verifymode vm = new Verifymode();  
      if (true) { //Успешная аутентификация  
          vm.Verify = true;  
          vm.Claims = new Claim[] {  
              new Claim("UserId", "123"),  
              new Claim("Name", "admin"),  
              new Claim("GivenName", "sdfq")  
          };  
       } else {  
           //Ошибка аутентификации  
           vm.Verify = false;  
           vm.ERRMessage = "XXX ошибка!";  
        }  
        return vm;  
    }  
}

<PropertyGroup>  
    <TargetFramework>net6.0</TargetFramework>  
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>  
    <GenerateDocumentationFile>True</GenerateDocumentationFile>  
    <EnableDynamicLoading>true</EnableDynamicLoading>  
</PropertyGroup>

{  
    RemoteService remoteService = new RemoteService("TEST"); //"TEST" - это имя, которое вы зарегистрировали для API  
    remoteService.Start();  
}```  

Измените файл конфигурации:  

```{  
"ServerIP": "127.0.0.1", //IP-адрес, который нужно привязать к компьютеру  
"Port": 10098, //Порт, используемый для привязки шлюза  
"Microcenter": "127.0.0.1:8001" //IP и порт сервисного центра  
}```  

Создайте новую библиотеку классов в качестве реализации бизнес-логики и добавьте ссылку на wRPCService, доступную через NuGet. Консольное приложение должно ссылаться на эту новую библиотеку бизнес-классов.  

Создайте класс, наследующий от FunctionBase.  
FunctionBase содержит свойства Cookies и Headers, которые могут использоваться для передачи содержимого HTTP-запросов.  
Добавьте атрибут Route к классу, чтобы указать маршрут API.  
Используйте атрибут InstallFun для установки метода, который будет использоваться для обработки запросов.  
Укажите тип запроса с помощью FunAttribute.  
Реализуйте метод бизнес-логики, используя async и возвращая IApiResult для унифицированного формата ответа. **Текст запроса на русском языке:**

API-получение HTTP header информации.

Сначала необходимо изменить файл конфигурации в gateway:
>  
  "Headers": [ "token" ]//добавляем необходимые для получения HTTP header.

[InstallFun(FunAttribute.Get, "тестирование")]
public string ff22()
{ 
  var value = this.Headers["соответствующий KEY"];
  return "";
}

API-получение информации OAuth2.0 аутентификации, которая содержит следующие данные:

context.Result = new GrantValidationResult(
                         subject: context.UserName,
                         authenticationMethod: "custom",
                         claims: new Claim[] {
                            new Claim("UserId", "ceshi123"),
                            new Claim("Name","ceshi"),
                            new Claim("Phone", "135135"),
                            new Claim("Role","admin"),
                             new Claim("Area","41")
                         });

Затем необходимо изменить файл конфигурации в gateway:
> "Cookies": [ "Areacode", "Role", "UserId", "Name", "Phone" ].

[InstallFun(FunAttribute.Get, "тестирование")]
public string ff22()
{ 
  var value = this.Cookies["соответствующий KEY"];
  return "";
}

Использование унифицированных правил ответа и упрощение использования метода.

[Route("api/test")]
public class testclass : ApiBase<object>//наследование от ApiBase<object>.
{
    public async Task<ApiResult<String>> test()
    {
        return await TRY(async () =>
        {
// написать собственный метод
            return "";
        });
    }
    public async Task<IApiResult> testapi()
    {
        return await TRY(async () =>
        {
// написать собственный метод
            return "";
        });
    }
}

В wRPCService версии v1.0.15 и выше встроен AOP (аспектно-ориентированное программирование). Можно использовать следующий способ для реализации унифицированного формата ответа (не поддерживается автоматическое получение унифицированного формата и отображение в документации Swagger):

Способ использования: добавьте атрибут UnifyResult к классу или методу. Если какой-то метод не использует унифицированный формат ответа, добавьте атрибут [UnifyResult(DontUse = true)].

[Route("api/test")]
[UnifyResult]
public class testclass : ApiBase<object>//наследование от ApiBase<object>.
{
    [UnifyResult]
    public async Task<string> test()
    {
        // написать собственный метод
        return "";
    }
    [UnifyResult(DontUse = true)]//вернуть исходный ответ
    public async Task<string> testapi()
    {
        // написать собственный метод
        return "";
    }
}

Также можно реализовать свой собственный унифицированный формат ответа (не поддерживается автоматическое получение унифицированного формата и отображение в документации Swagger).

Ниже представлен код атрибута UnifyResult, который вы можете использовать для создания своего собственного атрибута. Достаточно наследовать от AopAttribute:

/// <summary>
/// Унифицированный результат возврата, вы также можете создать свой собственный, или продолжать использовать TRY
/// </summary>
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = false)]
public class UnifyResultAttribute : AopAttribute
{
    public bool DontUse { get; set; } = false;
    /// <summary>
    /// Try ставится на первое место
    /// </summary>
    public override int Order { get; set; } = int.MinValue;
    public override bool OnActionExecuted(AopContext context)
    {
        if (DontUse) return true;
        var o = new ApiResult<object>() { code = 200, message = "операция выполнена успешно" };
        if (context.Exception is null)
        {
            o.data = context.Result;
        }
        else
        {
            context.Exception = context.Exception.GetBaseException();
            //асинхронный переход в синхронный здесь для определения типа исключения
            if (context.Exception is ApiException e)
            {
                o.code = 0;
                o.message = $"операция не удалась: {e.Message}";
                o.errData = e.data;
            }
            else
            {
                o.code = 500;
                o.message = $"исключение вызова интерфейса: {context.Exception.Message}";
                o.errData = context.Exception.StackTrace;
            }
        }
        context.Result = o;
        return base.OnActionExecuted(context);
    }
}

Механизм кэширования памяти.

В wRPCService версии v1.0.15 и выше добавлен механизм кэширования на основе Microsoft.Extensions.Caching.Memory. Реализуется с помощью атрибутов.

[Route("api/test")]
[MemoryCache(AbsoluteExpiration =3600,SlidingExpiration =60)]
public class testclass : ApiBase<object>//наследование от ApiBase<object>.
{
    [MemoryCache(AbsoluteExpiration

*Обратите внимание, что это перевод исходного текста, и он может содержать неточности или ошибки.* **Особенности**

* **AbsoluteExpiration**: кэш с фиксированным окном, единица измерения — секунды. По умолчанию составляет 3600 секунд (60 минут). Для отмены используется значение -1. Не поддерживает запросы с точным временем.

* **SlidingExpiration**: кэш со скользящим окном, единица измерения — секунды. Значение по умолчанию — 60 секунд. Для отмены используется -1.

* **DependCache**: зависимость кэша, ключ — «键名».

* **Key**: ключ кэша. По умолчанию равен имени метода + хэш параметров. Если требуется зависимость кэша, необходимо задать имя ключа самостоятельно.

**Поддержка AOP-особенностей**

В wRPCService версии v1.0.15 и выше добавлена поддержка обработки AOP-механизмов. Можно реализовать собственные компоненты AOP, такие как кэш, унифицированная обработка или логирование.

Для реализации необходимо:

1. Добавить особенность и наследовать от wRPCService.AopAttribute. Установить область действия особенности.

2. Реализовать методы, определённые в AopAttribute, например, для прерывания метода вернуть false.

3. Изменить значения в AopContext в зависимости от ситуации.

4. Применить атрибут к классу или методу API.

**Вызов и проверка**

Вызовы через HTTP/HTTPS Restful через шлюз могут быть без проверки или с проверкой.

Без проверки:

С проверкой:

RPC-вызов удалённого метода не через шлюз:

Создать программу управления консолью приложения, которая ссылается на пакет wRPCclient.

**Другие примечания**

1. Каждый RPC-сервис и шлюз создают файл funconfig.json в каталоге, который содержит информацию о зарегистрированных серверах и методах. Это может быть использовано для расширения мониторинга и других функций в будущем.

2. После отключения регистрационного центра происходит автоматическая персистентность зарегистрированной информации. При каждом запуске проверяется, запущен ли удалённый сервис.

3. События удалённого вызова используют архитектуру weaving-socket, время отклика составляет от 0 до 1 миллисекунды.

4. API-шлюз использует одно соединение с очередью блокировок для каждого удалённого RemoteService.

5. Несколько RemoteService могут иметь одинаковые методы и маршруты, и выбор осуществляется путём голосования.

6. Когда RemoteService отключается от регистрационного центра, API-шлюз немедленно обновляет связанные методы для вызова прерывания.

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

8. Конфигурация шлюза фиксирована. Если шлюз не настроен на использование регистрационного центра, можно написать содержимое funconfig.json самостоятельно, чтобы запустить запрос на обслуживание только через шлюз.

9. Каждый раз, когда шлюз вызывает API-службу, регистрационный центр получает соответствующий журнал, который сохраняется в каталоге.