Detaillierter Vergleich mehrerer Versionen von WebApi in ASP.Net Core (Bild)

Dieser Artikel stellt hauptsächlich den Vergleich mehrerer Versionskontrollen von ASP.Net Core WebApi vor. Der Herausgeber findet ihn ziemlich gut. Jetzt werde ich ihn mit Ihnen teilen und Ihnen eine Referenz geben. Folgen wir dem Editor, um einen Blick darauf zu werfen

1. Vorteile der Versionskontrolle:

(1) Es hilft, Funktionen rechtzeitig zu starten Art und Weise und wird bestehende Systeme nicht stören.

(2) Es kann auch dazu beitragen, ausgewählten Kunden zusätzliche Funktionen bereitzustellen.

Die API-Versionskontrolle kann auf verschiedene Arten gesteuert werden, wie folgt:

(1) Hängen Sie die Version in der URL oder als Abfragezeichenfolgenparameter an,

(2) In diesem Beitrag werfen wir einen Blick darauf, wie mehrere Versionen der ASP.NET Core-Web-API unterstützt werden.

1. Erstellen Sie ein asp.net-Core-Webapi-Projekt und verweisen Sie auf das NuGet-Paket: Install-Package Microsoft.AspNetCore.Mvc.Versioning -Version 2.0.0

Das Projekt und das Installationspaket sind fertig, dann müssen wir den folgenden Code zur Methode „ConfigureServices“ in Startup.cs hinzufügen:

Wie Sie sehen, sind 3 verschiedene Optionen konfiguriert.

ReportAPIVersions: Dies ist optional. Wenn es jedoch auf „true“ gesetzt ist, gibt die API im Antwortheader Informationen zur unterstützten Version zurück.
AssumeDefaultVersionWhenUnspecified: Diese Option wird für Anfragen verwendet, die keine Version bereitstellen. Standardmäßig wird als API-Version 1.0 angenommen.
DefaultApiVersion: Diese Option wird verwendet, um die Standard-API-Version anzugeben, die verwendet werden soll, wenn in der Anfrage keine Version angegeben ist. Standardmäßig wird Version 1.0 verwendet.
Dies sind alle Konfigurationen und Einstellungen. Jetzt werden wir die verschiedenen Möglichkeiten sehen, auf API-Versionen zuzugreifen.

2. Implementieren Sie die Versionskontrolle über QueryString

Öffnen Sie unseren Controller und fügen Sie die ApiVersion-Funktion hinzu, wie im folgenden Code gezeigt:

Der obige Code ist als Version 1.0. Sie können auch eine andere Controller-Klasse mit demselben Namen in einem anderen Namespace erstellen und die API-Version auf Version 2.0 festlegen. Wie im Bild unten gezeigt:

Das ist es. Gehen Sie nun zum Browser und greifen Sie auf den Controller zu. Sie sollten eine Ausgabe des API-Controllers der Version 1.0 sehen, da dieser auf die Standardeinstellung eingestellt ist. Hängen Sie nun api-version=2 in die URL ein und Sie sollten die Ausgabe des API-Controllers der Version 2.0 sehen.

2. Implementiert durch URL-Pfadsegment:

api/v1/values

• api/v2/values

• Still Um das obige Projekt auszuführen, müssen Sie lediglich den folgenden Code zu den Controllern v1 und v2 hinzufügen. Wie unten gezeigt:

Ebenso müssen Sie die Routing-Parameter für alle anwendbaren Standorte aktualisieren. Mit dieser Änderung ist beim Zugriff auf die API-Schnittstelle immer eine Versionsnummer erforderlich. Sie können über api/v1/values ​​​​auf Version 1.0 und über api/v2/values ​​​​auf Version 2.0 zugreifen, indem Sie die Versionsnummer in der URL ändern. Einfach und sieht sauberer aus.

Die Testergebnisse lauten wie folgt:

3. Implementieren Sie die Versionskontrolle über HTTP Header

Bei den beiden oben genannten Methoden muss die URL geändert werden, um die Versionskontrolle zu unterstützen. Wenn Sie jedoch möchten, dass die URL der API sauber bleibt, können die API-Versionsinformationen auch durch Anhängen eines HTTP-Headers übergeben werden. Damit dies funktioniert, müssen Sie die ApiVersionReader-Optionen konfigurieren. Der Code lautet wie folgt:

Die hervorgehobene Zeile sagt uns, dass der Header „api-version“ jetzt der erwartete Speicherort für die API-Versionsnummer ist. Stellen Sie sicher, dass die Routenattribute keine Versionsdetails enthalten. Habe es also getestet und hier ist das Ergebnis:

Wenn Sie 2.0 als Wert für „API-Version“ angeben, wird der Controller der Version 2.0 aufgerufen und die Ausgabe zurückgegeben.

Einfach und leicht einzurichten. Allerdings funktioniert die Abfragezeichenfolgenparametermethode für die Versionierung jetzt nicht mehr. Sobald der Header festgelegt ist, können keine Abfragezeichenfolgenparameter mehr angegeben werden. Wenn Sie beide Fälle unterstützen möchten, verwenden Sie QueryStringOrHeaderApiVersionReader anstelle von HeaderApiVersionReader. Der Code lautet wie folgt:

Daher werden jetzt Abfragezeichenfolgenparameter und Header unterstützt. Der Standardname des Abfragezeichenfolgenparameters lautet api-version. Sie können den Konstruktor also leer lassen. Wenn jedoch ein anderer Name erforderlich ist, müssen Sie ihn angeben. Sie können auch unterschiedliche Namen für Abfragezeichenfolgenparameter und Header verwenden. Denken Sie daran, dass wir ReportApiVersions auch auf true setzen, wodurch die Versionsinformationen im Antwortheader zurückgegeben werden. Siehe Bild unten.

Schauen wir uns nun ein paar weitere Optionen an.

MapToApiVersion-Parameterverwendung:

Das MapToApiVersion-Attribut ermöglicht die Zuordnung einer einzelnen API-Operation zu einer beliebigen Version. Mit anderen Worten: ein einzelner Controller, der mehrere Versionen unterstützt. Controller verfügen möglicherweise nur über von Version 3 unterstützte API-Aktionsmethoden. In diesem Fall können Sie MapToApiVersion verwenden. Schauen Sie sich den Code unten an.

Der obige Code bedeutet: öffentliche Zeichenfolge Get() Diese Methode wird nur in Version 1.0 unterstützt, und die öffentliche Zeichenfolge Getv3()-Methode wird nur in Version 3.0 unterstützt.

Es gibt Bilder und echte Bilder, es ist sehr flexibel, es gefällt mir sehr gut.

Verwendung des Deprecated-Parameters:

Bei der Unterstützung mehrerer API-Versionen werden einige Versionen mit der Zeit irgendwann veraltet sein. Um eine oder mehrere API-Versionen als veraltet zu markieren, dekorieren Sie Ihren Controller einfach mit „Veraltet“. Dies bedeutet nicht, dass API-Versionen nicht unterstützt werden. Sie können diese Version weiterhin aufrufen. Dies ist lediglich eine Möglichkeit, aufrufende API-Benutzer darauf aufmerksam zu machen, dass die folgenden Versionen in Zukunft veraltet sein werden.

Wenn Sie oben „Veraltet“ auf TRUE setzen, bedeutet dies, dass Version 1.0 in Zukunft veraltet sein wird. Wenn Sie auf unsere API-Schnittstelle zugreifen, können Sie im Antwortheader die folgenden Informationen sehen, wie in der folgenden Abbildung dargestellt:

Nutzung der ApiVersionNeutral-Funktion:

ApiVersionNeutral Funktionsdefinition Diese API unterstützt keine Versionierung mehr. Dies ist nützlich für APIs, die sich genau gleich verhalten, unabhängig davon, ob sie die API-Versionierung unterstützen, oder für ältere APIs, die die API-Versionierung nicht unterstützen. Daher können Sie die Eigenschaft ApiVersionNeutral hinzufügen, um die Versionskontrolle zu verlassen.

Versionsinformationen abrufen (Versionsinformationen)

Wenn Sie wissen möchten, auf welche Version des Clients zugegriffen wird, können Sie diese Funktion wie folgt implementieren Code :

Zusammenfassend lässt sich sagen, dass mehrere Versionen der API dazu beitragen können, erweiterte Funktionen auf effiziente Weise bereitzustellen und gleichzeitig die Nachverfolgung von Änderungen zu erleichtern. In diesem Artikel haben wir gesehen, wie man der ASP.NET coreWEB-API Unterstützung für mehrere Versionen hinzufügt. Das Nuget-Paket unterstützt die Versionierung über Abfragezeichenfolgenparameter, das Hinzufügen von Pfadsegmenten in URLs und über Header. Es bietet außerdem API-Operationen für einzelne Versionen und die Möglichkeit, Versionen abzulehnen.

Ist es möglich, eine Versionskontrolle einer API zu erreichen, ohne auf Pakete von Drittanbietern zurückzugreifen?

Viertel. Ultimative Version (ohne NuGet-Paket) asp.net-Kern-Web-API-Versionskontrolle

Erstellen Sie ein neues Kern-API-Projekt:

Erstellen Sie im Ordner „VersionControl“ eine neue Klasse „NameSpaceVersionRoutingConvention“, die die IApplicationModelConvention-Schnittstelle implementiert. Der Code lautet wie folgt:

public class NameSpaceVersionRoutingConvention:IApplicationModelConvention
  {
    private readonly string apiPrefix;
    private const string urlTemplate = "{0}/{1}/{2}";
    public NameSpaceVersionRoutingConvention(string apiPrefix = "api")
    {
      this.apiPrefix = apiPrefix;
    }

    public void Apply(ApplicationModel application)
    {
      foreach (var controller in application.Controllers)
      {
        
        var hasRouteAttribute = controller.Selectors
        .Any(x => x.AttributeRouteModel != null);
        if (!hasRouteAttribute)
        {
          continue;
        }
        var nameSpaces = controller.ControllerType.Namespace.Split('.');
        //获取namespace中版本号部分
        var version = nameSpaces.FirstOrDefault(x => Regex.IsMatch(x, @"^v(\d+)$"));
        if (string.IsNullOrEmpty(version))
        {
          continue;
        }
        string template = string.Format(urlTemplate, apiPrefix, version,
        controller.ControllerName);
        controller.Selectors[0].AttributeRouteModel = new AttributeRouteModel()
        {
          Template = template
        };
      }
    }
  }

Debug-Code Es wurde festgestellt, dass diese Methode nur ausgeführt wird, wenn das Programm zum ersten Mal ausgeführt wird, und danach nicht mehrmals ausgeführt wird, sodass sie sehr effizient ist.

5. Zusammenfassung:

Das obige ist der detaillierte Inhalt vonDetaillierter Vergleich mehrerer Versionen von WebApi in ASP.Net Core (Bild). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!