Udostępnij za pośrednictwem


Przetestuj, czy moja aplikacja prawidłowo obsługuje ograniczanie przepustowości

Testowanie ograniczania przepustowości jest trudne, ponieważ występuje rzadko, tylko wtedy, gdy serwer hostujący interfejs API jest mocno obciążony. Za pomocą serwera proxy deweloperskiego można symulować ograniczanie przepustowości w dowolnym interfejsie API i sprawdzić, czy aplikacja obsługuje ją poprawnie.

Aby symulować ograniczanie przepustowości dla dowolnego interfejsu API, użyj metody GenericRandomErrorPlugin. Jeśli używany interfejs API zwraca Retry-After nagłówek, użyj polecenia RetryAfterPlugin , aby sprawdzić, czy aplikacja wycofała się zgodnie z instrukcją interfejsu API.

Symulowanie ograniczania przepustowości w dowolnym interfejsie API

Aby rozpocząć, włącz element GenericRandomErrorPlugin w pliku konfiguracji proxy deweloperskiego.

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/rc.schema.json",
  "plugins": [
    {
      "name": "GenericRandomErrorPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
      "configSection": "errorsContosoApi",
      "urlsToWatch": [
        "https://api.contoso.com/*"
      ]
    }
  ]
}

Następnie skonfiguruj wtyczkę tak, aby korzystała z pliku zawierającego błędy, które chcesz symulować.

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/rc.schema.json",
  "plugins": [
    {
      "name": "GenericRandomErrorPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
      "configSection": "errorsContosoApi",
      "urlsToWatch": [
        "https://api.contoso.com/*"
      ]
    }
  ],
  "errorsContosoApi": {
    "errorsFile": "errors-contoso-api.json"
  }
}

W pliku błędów zdefiniuj odpowiedź ograniczania przepustowości, tak aby była zgodna z rzeczywistą odpowiedzią ograniczania przepustowości interfejsu API:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/genericrandomerrorplugin.schema.json",
  "errors": [
    {
      "request": {
        "url": "https://api.contoso.com/*"
      },
      "responses": [
        {
          "statusCode": 429,
          "headers": [
            {
              "name": "Content-Type",
              "value": "application/json"
            }
          ],
          "body": {
            "code": "TooManyRequests",
            "message": "Too many requests"
          }
        }
      ]
    }
  ]
}

Uruchom serwer Dev Proxy z użyciem pliku konfiguracji i przetestuj aplikację, aby zobaczyć, jak obsługuje ograniczanie prędkości.

Przetestuj poprawne wycofanie przy użyciu nagłówka Retry-After

Wiele interfejsów API używa nagłówka Retry-After odpowiedzi, aby poinstruować aplikację do wstrzymania się na określony czas. Podczas symulacji odpowiedzi throttlingu za pomocą Dev Proxy można skonfigurować nagłówek Retry-After na wartość statyczną lub użyć wartości dynamicznej, która sprawdza, czy aplikacja czeka zgodnie z instrukcją przed ponownym wywołaniem API.

Aby skonfigurować nagłówek Retry-After na wartość statyczną, dodaj nagłówek do odpowiedzi na ograniczanie przepustowości:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/genericrandomerrorplugin.schema.json",
  "errors": [
    {
      "request": {
        "url": "https://api.contoso.com/*"
      },
      "responses": [
        {
          "statusCode": 429,
          "headers": [
            {
              "name": "Content-Type",
              "value": "application/json"
            },
            {
              "name": "Retry-After",
              "value": "60"
            }
          ],
          "body": {
            "code": "TooManyRequests",
            "message": "Too many requests"
          }
        }
      ]
    }
  ]
}

W tym przykładzie Retry-After nagłówek jest ustawiony na 60 sekund. Podczas konfigurowania nagłówka na wartość statyczną serwer proxy dewelopera nie kontroluje, czy aplikacja czeka przed ponownym wywołaniem interfejsu API.

Aby sprawdzić, czy aplikacja czeka prawidłowo przed ponownym wywołaniem interfejsu API, zmień wartość nagłówka na @dynamic:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/genericrandomerrorplugin.schema.json",
  "errors": [
    {
      "request": {
        "url": "https://api.contoso.com/*"
      },
      "responses": [
        {
          "statusCode": 429,
          "headers": [
            {
              "name": "Content-Type",
              "value": "application/json"
            },
            {
              "name": "Retry-After",
              "value": "@dynamic"
            }
          ],
          "body": {
            "code": "TooManyRequests",
            "message": "Too many requests"
          }
        }
      ]
    }
  ]
}

Ponadto rozszerz konfigurację serwera proxy dev za pomocą polecenia RetryAfterPlugin.

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/rc.schema.json",
  "plugins": [
    {
      "name": "RetryAfterPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
      "urlsToWatch": [
        "https://api.contoso.com/*"
      ]
    },
    {
      "name": "GenericRandomErrorPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
      "configSection": "errorsContosoApi",
      "urlsToWatch": [
        "https://api.contoso.com/*"
      ]
    }
  ],
  "errorsContosoApi": {
    "errorsFile": "errors-contoso-api.json"
  }
}

Uwaga

Dodaj element RetryAfterPlugin przed elementem GenericRandomErrorPlugin w pliku konfiguracji. Jeśli dodasz to później, żądanie zakończy się niepowodzeniem przez GenericRandomErrorPlugin zanim RetryAfterPlugin będzie miało szansę to obsłużyć.

Ta wtyczka śledzi odpowiedzi ograniczania przepustowości i wymusza niepowodzenie żądań wystawionych dla interfejsów API, które są nadal ograniczane.

Więcej informacji