

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Pfad-Routing-Muster
<a name="api-routing-path"></a>

Beim Routing nach Pfaden werden mehrere oder alle APIs unter demselben Hostnamen gruppiert und Dienste mithilfe eines Anforderungs-URI isoliert, z. B. oder. `api.example.com/service-a` `api.example.com/service-b`

## Typische Anwendungsfälle
<a name="path-routing-use-case"></a>

Die meisten Teams entscheiden sich für diese Methode, weil sie eine einfache Architektur wollen – ein Entwickler muss sich nur eine URL merken, zum Beispiel `api.example.com`, um mit der HTTP-API zu interagieren. Die API-Dokumentation ist oft leichter zu verdauen, da sie häufig zusammengehalten wird, anstatt auf verschiedene Portale aufgeteilt zu werden oder. PDFs

Pfadbasiertes Routing gilt als einfacher Mechanismus für die gemeinsame Nutzung einer HTTP-API. Es ist jedoch mit betrieblichem Aufwand wie Konfiguration, Autorisierung, Integrationen und zusätzlicher Latenz aufgrund mehrerer Übergaben verbunden. Außerdem sind ausgereifte Änderungsmanagementprozesse erforderlich, um sicherzustellen, dass eine Fehlkonfiguration nicht zu einer Unterbrechung aller Services führt.

Bei gibt es mehrere Möglichkeiten AWS, eine API gemeinsam zu nutzen und effektiv zum richtigen Service weiterzuleiten. In den folgenden Abschnitten werden drei Ansätze behandelt: HTTP Service Reverse Proxy, API Gateway und Amazon CloudFront. Keiner der vorgeschlagenen Ansätze zur Vereinheitlichung von API-Services stützt sich auf die Downstream-Services, die auf AWS laufen. Die Services können überall ohne Probleme oder mit jeder Technologie ausgeführt werden, solange sie HTTP-kompatibel sind.

## HTTP-Service-Reverse-Proxy
<a name="path-routing-proxy"></a>

Sie können einen HTTP-Server wie [NGINX](https://www.f5.com/go/product/welcome-to-nginx) verwenden, um dynamische Routing-Konfigurationen zu erstellen. In einer [Kubernetes-Architektur](https://kubernetes.io/) können Sie auch eine Eingangsregel erstellen, die dem Pfad zu einem Service entspricht. (Dieser Leitfaden behandelt nicht den Kubernetes-Eingang. Weitere Informationen finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource).)

Die folgende Konfiguration für NGINX ordnet dynamisch eine HTTP-Anfrage von `api.example.com/my-service/` zu `my-service.internal.api.example.com` zu.

```
server {
    listen  80;

    location (^/[\w-]+)/(.*) {
        proxy_pass $scheme://$1.internal.api.example.com/$2;
    }
}
```

Das folgende Diagramm veranschaulicht die Methode des HTTP-Service-Reverse-Proxy.



![\[Verwenden eines HTTP-Service-Reverse-Proxys für das Pfad-Routing.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png)


Dieser Ansatz kann für einige Anwendungsfälle ausreichend sein, in denen keine zusätzlichen Konfigurationen verwendet werden, um die Verarbeitung von Anfragen zu starten, sodass die nachgelagerte API Metriken und Protokolle sammeln kann.

Um für die Produktion betriebsbereit zu sein, müssen Sie in der Lage sein, die Beobachtbarkeit auf jeder Ebene Ihres Stacks hinzuzufügen, zusätzliche Konfigurationen vorzunehmen oder Skripte hinzuzufügen, um Ihren API-Eingangspunkt so anzupassen, dass fortgeschrittene Features wie Ratenbegrenzung oder Nutzungs-Tokens möglich sind.

### Vorteile
<a name="path-routing-proxy-pros"></a>

Das ultimative Ziel der Reverse-Proxy-Methode für den HTTP-Service besteht darin, einen skalierbaren und verwaltbaren Ansatz für die Vereinheitlichung APIs in einer einzigen Domain zu schaffen, sodass diese für jeden API-Nutzer kohärent erscheint. Dieser Ansatz ermöglicht es Ihren Serviceteams auch, ihre eigenen Lösungen bereitzustellen und zu verwalten APIs, wobei der Aufwand nach der Bereitstellung minimal ist. AWS verwaltete Dienste für die Rückverfolgung, wie [AWS X-Ray](https://aws.amazon.com/xray/)oder [AWS WAF](https://aws.amazon.com/waf/), sind hier weiterhin anwendbar.

### Nachteile
<a name="path-routing-proxy-cons"></a>

Der größte Nachteil dieses Ansatzes ist das umfangreiche Testen und Verwalten der erforderlichen Infrastrukturkomponenten, obwohl dies möglicherweise kein Problem darstellt, wenn Sie über Teams für Site Reliability Engineering (SRE) verfügen.

Bei dieser Methode gibt es einen Kostenschwellenwert. Bei niedrigen bis mittleren Mengen ist sie teurer als einige der anderen Methoden, die in diesem Handbuch beschrieben werden. Bei hohen Volumen ist sie sehr kostengünstig (etwa 100 000 Transaktionen pro Sekunde oder besser).

## API Gateway
<a name="path-routing-gateway"></a>

Der [Amazon API Gateway Gateway-Service](https://aws.amazon.com/api-gateway/) (REST APIs und HTTP APIs) kann den Datenverkehr auf eine Weise weiterleiten, die der Reverse-Proxy-Methode des HTTP-Service ähnelt. Die Verwendung eines API-Gateways im HTTP-Proxymodus bietet eine einfache Möglichkeit, viele Services in einen Einstiegspunkt zur Top-Level-Subdomain `api.example.com` einzubinden und dann Anfragen an den verschachtelten Service weiterzuleiten, zum Beispiel `billing.internal.api.example.com`.

Sie möchten wahrscheinlich nicht zu differenziert vorgehen und jeden Pfad in jedem Service im Root- oder Core-API-Gateway abbilden. Entscheiden Sie sich stattdessen für Wildcard-Pfade, wie z. B. `/billing/*`, um Anfragen an den Abrechnungsservice weiterzuleiten. Indem Sie nicht jeden Pfad im Root- oder Core-API-Gateway zuordnen, gewinnen Sie mehr Flexibilität APIs, da Sie das Root-API-Gateway nicht bei jeder API-Änderung aktualisieren müssen.

![\[Pfad-Routing über API-Gateway.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png)


### Vorteile
<a name="path-routing-gateway-pros"></a>

Für die Steuerung komplexerer Workflows, wie z. B. das Ändern von Anforderungsattributen, stellt APIs REST die Apache Velocity Template Language (VTL) zur Verfügung, sodass Sie die Anfrage und Antwort ändern können. REST APIs kann zusätzliche Vorteile wie diese bieten:
+ [Authentifizierung N/Z mit AWS Identity and Access Management (IAM),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [[Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) oder Autorisierern AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)
+ [AWS X-Ray zur Rückverfolgung](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html)
+ [Integration mit AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)
+ [Grundsätzliche Ratenbegrenzung](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ Nutzungs-Tokens für die Einteilung der Verbraucher in verschiedene Buckets (siehe [Drosselung von API-Anfragen für besseren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) in der API-Gateway-Dokumentation)

### Nachteile
<a name="path-routing-gateway-cons"></a>

Bei hohem Volumen könnten die Kosten für einige Benutzer ein Problem darstellen.

## CloudFront
<a name="path-routing-cloudfront"></a>

Sie können die [dynamische Herkunftsauswahlfunktion](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html) in [Amazon](https://aws.amazon.com/cloudfront/) verwenden CloudFront, um bedingt einen Ursprung (einen Service) auszuwählen, um die Anfrage weiterzuleiten. Sie können dieses Feature verwenden, um eine Reihe von Services über einen einzigen Hostnamen weiterzuleiten, z. B. `api.example.com`.

### Typische Anwendungsfälle
<a name="path-routing-cloudfront-usecase"></a>

Die Routing-Logik ist als Code in der Lambda @Edge -Funktion enthalten und unterstützt daher hochgradig anpassbare Routing-Mechanismen wie A/B Tests, Canary-Releases, Feature-Flagging und Pfadumschreibung. Dies wird im folgenden Diagramm veranschaulicht.

![\[Pfadweiterleitung durch. CloudFront\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png)


### Vorteile
<a name="path-routing-cloudfront-pros"></a>

Wenn Sie API-Antworten zwischenspeichern müssen, ist diese Methode eine gute Möglichkeit, eine Sammlung von Services hinter einem einzigen Endpunkt zu vereinen. Es ist eine kostengünstige Methode zur Vereinheitlichung von Sammlungen von APIs.

 CloudFront Unterstützt außerdem die [Verschlüsselung auf Feldebene](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html) sowie die Integration mit AWS WAF Basic Rate Limiting und Basic. ACLs

### Nachteile
<a name="path-routing-cloudfront-cons"></a>

Diese Methode unterstützt maximal 250 Ursprünge (Services), die vereinheitlicht werden können. Dieses Limit ist für die meisten Bereitstellungen ausreichend, kann jedoch bei einer großen Anzahl von APIs Diensten zu Problemen führen, wenn Sie Ihr Serviceportfolio erweitern.

Die Aktualisierung der Lambda @Edge -Funktionen dauert derzeit einige Minuten. CloudFront es dauert außerdem bis zu 30 Minuten, bis die Übertragung der Änderungen an allen Präsenzpunkten abgeschlossen ist. Dadurch werden letztlich weitere Updates blockiert, bis sie abgeschlossen sind.