Antworten zur Performanceverbesserung cachen
Erfahren Sie, wie Sie Antwort-Caching-Anforderungs- und Antwort-Policys verwenden, um die Anzahl der Anforderungen zu reduzieren, die mit API Gateway an Backend-Services gesendet werden.
In der Regel sollten Sie vermeiden, unnötige Last auf Backend-Services zu legen, um die Performance zu verbessern und Kosten zu senken. Eine Möglichkeit, diese Last zu reduzieren, besteht darin, Antworten auf Anforderungen zu cachen, falls die Antworten später wiederverwendet werden können. Wenn ähnliche Anforderungen empfangen werden, können sie erfüllt werden, indem Daten aus einem Antwortcache abgerufen werden, anstatt die Anforderung an den Backend-Service zu senden.
Der API Gateway-Service kann mit einem externen Cacheserver integriert werden, auf den Sie bereits Zugriff haben, z.B. mit einem Redis- oder KeyDB-Server. Sie können vom API-Gateway-Service verwaltete API-Gateways konfigurieren, um:
- Speichern Sie Daten auf dem Cacheserver, die von einem Backend-Service als Antwort auf eine ursprüngliche Anforderung zurückgegeben wurden.
- Rufen Sie zuvor gespeicherte Daten vom Cacheserver als Antwort auf eine spätere Anforderung ab, die der ursprünglichen Anforderung ähnlich ist, ohne die spätere Anforderung an den Backend-Service zu senden.
So konfigurieren Sie ein API-Gateway für das Antwort-Caching:
- Antwort-Caching im API-Gateway aktivieren (siehe Antwort-Caching in einem API-Gateway aktivieren)
- Antwort-Caching für einzelne Routen im API-Gateway mit Anforderungs-Policys und Antwort-Policys einrichten (siehe Antwort-Caching-Anforderungs- und Antwort-Policys hinzufügen)
Sie können das Antwort-Caching wie folgt einrichten:
- die Konsole verwenden
- eine JSON-Datei bearbeiten
Wie funktioniert das Antwort-Caching?
Wenn Sie ein API-Gateway für das Antwort-Caching aktiviert haben, analysiert das API-Gateway Anforderungen von API-Clients auf Routen mit Antwort-Caching-Policys. Das API-Gateway versucht, eine neue Anforderung mit vorherigen ähnlichen Anforderungen abzugleichen, für die Antworten bereits auf dem Cacheserver gespeichert sind. Das API-Gateway speichert Antworten auf GET-, HEAD- und OPTIONS-Anforderungen auf dem Cacheserver, sofern die Antworten den HTTP-Statuscode 200, 204, 301 oder 410 aufweisen. Beachten Sie, dass das API-Gateway die eingerichteten Antwort-Caching-Anforderungs- und Antwort-Policys verwendet und alle Cachekontrollheader (sofern vorhanden) in der Anforderung oder Antwort ignoriert.
Um Antworten auf dem Cacheserver eindeutig zu identifizieren, verwendet das API-Gateway Cacheschlüssel, die von den Anforderungen GET, HEAD und OPTIONS abgeleitet wurden, welche die Antworten ausgelöst haben. Standardmäßig umfasst ein Cache-Schlüssel:
- URL der Anforderung, die die Antwort ausgelöst hat (ohne Abfrageparameter in der URL)
- HTTP-Methode (eine der Optionen GET, HEAD oder OPTIONS)
- die OCID des API-Deployments, das die Anforderung empfangen hat
Um gecachte Antworten genauer mit bestimmten Anforderungen abzugleichen, können Sie Cacheschlüssel optional anpassen, indem Sie die Werte einer oder mehrerer Kontextvariablen aus der Anforderung zum Cacheschlüssel hinzufügen (siehe Hinweise zum Anpassen von Cacheschlüsseln).
Was als Nächstes geschieht, hängt davon ab, ob das API-Gateway die neue GET-, HEAD- oder OPTIONS-Anforderung mit einer Antwort aus einer vorherigen ähnlichen Anforderung abgleichen kann:
- Wenn das API-Gateway einen übereinstimmenden Cacheschlüssel auf dem Cacheserver findet, ruft das API-Gateway die entsprechenden Antwortdaten vom Cacheserver ab und sendet sie als Antwort an den API-Client.
- Wenn das API-Gateway keinen übereinstimmenden Cacheschlüssel im Cacheserver findet, leitet das API-Gateway die Anforderung an den Backend-Service weiter. Wenn der Backend-Service eine Antwort zurückgibt, sendet das API-Gateway die Antwort sowohl an den API-Client als auch speichert die Antwort mit einem neuen Cacheschlüssel auf dem Cacheserver.
X-Cache-Status
gibt wie folgt an, ob die Antwort vom Cacheserver abgerufen wurde:X-Cache-Status: HIT
gibt an, dass ein übereinstimmender Cacheschlüssel im Cacheserver gefunden wurde. Daher wurde die Antwort vom Cacheserver abgerufen.X-Cache-Status: MISS
gibt an, dass kein übereinstimmender Cacheschlüssel im Cacheserver gefunden wurde. Daher stammt die Antwort vom Backend-Service.X-Cache-Status: BYPASS
gibt an, dass der Cacheserver nicht geprüft wurde. Daher stammt die Antwort vom Backend-Service. Gründe für die Nichtprüfung des Cacheservers sind Probleme bei der Kommunikation mit dem Cacheserver und Konfigurationseinstellungen, die verhindern, dass Antworten auf bestimmte Anforderungen vom Cacheserver abgerufen werden.
Tipp: Wenn Antworten den zusätzlichen X-Cache-Status
-Header nicht enthalten sollen, entfernen Sie ihn mit einer Headertransformationsantwort-Policy (siehe Headertransformationsantwort-Policys hinzufügen).
Hinweise zu Antwort-Caching und Sicherheit
So stellen Sie sicher, dass Daten auf dem Cacheserver gespeichert und sicher abgerufen werden:
- Sie richten das API-Gateway zur Authentifizierung beim Cacheserver mit Zugangsdaten ein, die als Secret in einem Vault im Vault-Service gespeichert sind.
- Sie können angeben, ob eine sichere Verbindung über TLS (früher SSL) zwischen dem API-Gateway und einem TLS-fähigen Cacheserver eingerichtet werden soll und ob TLS-Zertifikate geprüft werden sollen. Beachten Sie, dass derzeit nur Zertifikate überprüft werden, die von öffentlichen Zertifizierungsstellen signiert wurden.
- Sie können eine Ablaufzeit angeben, um sicherzustellen, dass gecachte Daten über einen längeren Zeitraum nicht gespeichert werden und dass veraltete Daten nicht vom Cacheserver als Antwort auf eine spätere Anforderung zurückgegeben werden.
- Sie können die Anforderungs-URLs begrenzen, die mit Cacheschlüsseln übereinstimmen, indem Sie Cacheschlüssel so anpassen, dass sie mindestens einen Parameter in Anforderungs-URLs enthalten (siehe Hinweise zum Anpassen von Cacheschlüsseln).
- Sie können angeben, dass Antworten für Anforderungen, die Zugangsdaten enthalten, nicht gecacht werden sollen (siehe Hinweise zum Caching von Antworten für Anforderungen mit Zugangsdaten (privates Caching)).
Es liegt in Ihrer Verantwortung sicherzustellen, dass der Cacheserver selbst richtig konfiguriert ist, um die darauf gespeicherten Daten zu sichern. Insbesondere empfiehlt Oracle dringend, einen vorhandenen Cacheserver nicht wiederzuverwenden. Stattdessen empfiehlt Oracle, einen neuen Cacheserver ausschließlich für das API-Gateway-Antwort-Caching einzurichten und den Zugriff auf den Cacheserver nur auf API-Gateways zu beschränken.
Hinweise zum Caching von Antworten für Anforderungen mit Zugangsdaten (privates Caching)
Anforderungen können Autorisierungsheader enthalten, die Zugangsdaten zur Authentifizierung eines API-Clients mit einem Backend-Service enthalten. Die Zugangsdaten bieten in der Regel Zugriff auf Daten, die für eine Einzelperson oder Organisation privat sind. Beispiel: Mit einem Anforderungsautorisierungsheader, der ein Authentifizierungstoken enthält, kann eine Antwort ausgelöst werden, die Bankkontoinformationen enthält. Das Vorhandensein von Autorisierungsheadern in einer Anforderung ist ein Hinweis darauf, dass die Antwort sensibel sein und nur mit denjenigen geteilt werden kann, die sie sehen dürfen.
Wenn Sie Autorisiererfunktionen für die Authentifizierung und Autorisierung verwendet haben, identifiziert eine Authentifizierungs-Policy einen Header oder Abfrageparameter in einer Anforderung, die ein Zugriffstoken enthält (siehe Token an Autorisiererfunktionen übergeben, um Authentifizierung und Autorisierung zu API-Deployments hinzuzufügen). Das Vorhandensein des in einer Authentifizierungs-Policy identifizierten Headers oder Abfrageparameters in einer Anforderung ist auch ein Hinweis darauf, dass die Antwort vertraulicher Natur sein kann und nur mit denjenigen geteilt werden muss, die sie anzeigen dürfen.
Das Caching von Antworten für Anforderungen, die Autorisierungsheader enthalten oder einen in einer Authentifizierungs-Policy identifizierten Header oder Abfrageparameter enthalten, wird als "privates Caching" bezeichnet. Obwohl privates Caching in Zukunft Antworten auf ähnliche Anforderungen beschleunigen kann, hat es das Potenzial, die Datensicherheit zu gefährden. Um Sicherheitsverletzungen zu vermeiden, ist das private Caching daher standardmäßig deaktiviert. Sie können jedoch das private Caching auf Route-für-Route-Basis aktivieren.
Wenn Sie privates Caching aktivieren, wird empfohlen, den Cacheschlüssel so anzupassen, dass Antworten isoliert werden, sodass jede Antwort nur an die Antwort zurückgegeben wird, die sie sehen darf. Beispiel:
- Fügen Sie den Wert des Anforderungsautorisierungsheaders oder den Wert des in einer Authentifizierungs-Policy identifizierten Headers oder Abfrageparameters dem Cacheschlüssel als Kontextvariable aus einer Kontexttabelle hinzu.
- Wenn Sie Autorisiererfunktionen oder JWTs zur Authentifizierung und Autorisierung verwendet haben, fügen Sie den Wert einer Kontextvariablen, die den Anforderungs-Principal (wie
sub
oderprincipalId
) identifiziert, aus der Kontexttabellerequest.auth
zum Cacheschlüssel hinzu. Siehe Authentifizierung und Autorisierung zu API-Deployments hinzufügen.
Eine gecachte Antwort mit einem Wert im Cacheschlüssel für eine Kontextvariable wird nur als Antwort auf eine Anforderung mit einem übereinstimmenden Wert zurückgegeben.
Es liegt in Ihrer Verantwortung, eine Cacheschlüssel-Ergänzung anzugeben, die eine ausreichende Isolation zwischen gecachten Antworten bietet. Siehe Hinweise zum Anpassen von Cacheschlüsseln.
Hinweise zum Anpassen von Cacheschlüsseln
Antworten, die auf dem Cacheserver gespeichert sind, werden durch einen Cacheschlüssel eindeutig identifiziert. Standardmäßig wird ein Cacheschlüssel aus der URL der Anforderung abgeleitet, die die Antwort ausgelöst hat (ohne alle in der Anforderung vorhandenen Kontextvariablen), der HTTP-Methode und der OCID des API-Deployments. Um gecachte Antworten besser mit bestimmten Anforderungen abzugleichen, können Sie Cacheschlüssel optional anpassen, indem Sie die Werte einer oder mehrerer Kontextvariablen aus der Anforderung zum Cacheschlüssel hinzufügen. Wenn Sie privates Caching für Anforderungen aktivieren, die Autorisierungsheader enthalten oder einen Header oder Abfrageparameter enthalten, der in einer Authentifizierungs-Policy identifiziert wird, wird empfohlen, ihre Werte als Kontextvariablen zum Cacheschlüssel hinzuzufügen.
Um die Kontextvariablenwerte anzugeben, die dem Cacheschlüssel hinzugefügt werden sollen, verwenden Sie das Format <context-table-name>.[<key>]
. Dabei gilt:
<context-table-name>
istrequest.query
,request.headers
oderrequest.auth
<key>
ist eines der folgenden Elemente:- Ein Abfrageparametername, der in der Anforderung an die API enthalten ist
- Ein Headername, der in der Anforderung an die API enthalten ist
- Ein Authentifizierungsparameter, der von einer Autorisierungsfunktion zurückgegeben wird oder in einem JWT-Token enthalten ist
- das Headerfeld
Host
in der Anforderung an die API
Beispiel:
- Um den Wert der Kontextvariable
X-Username
zu einem Cacheschlüssel hinzuzufügen, wenn er in einem Anforderungsheader enthalten ist, geben Sierequest.headers[X-Username]
als Cacheschlüsselzusatz an. - Um den Anforderungs-Principal (die Person oder Anwendung, die die Anforderung sendet) zu einem Cacheschlüssel hinzuzufügen, wenn er als
sub
-Claim in einem JWT-Token enthalten ist, geben Sierequest.auth[sub]
als Cacheschlüsselzusatz an. - Um einem Cache-Schlüssel den Wert des
Authorization
-Headers hinzuzufügen, geben Sierequest.headers[Authorization]
als Cacheschlüssel hinzu. - Um den Wert eines Zugriffstokens, das von einer Autorisiererfunktion zurückgegeben wird und in einem Header mit dem Namen
X-Custom-Auth
enthalten ist, einem Cache-Schlüssel hinzuzufügen, geben Sierequest.headers[X-Custom-Auth]
als Cacheschlüssel hinzu. - Um den Wert des
Host
-Headerfelds, das in der Anforderung enthalten ist, einem Cache-Schlüssel hinzuzufügen, geben Sierequest.host
an.
Weitere Informationen zu kontextabhängigen Variablen finden Sie unter Kontextabhängige Variablen zu Policys und HTTP-Backend-Definitionen hinzufügen.
Voraussetzungen für das Antwort-Caching
Bevor Sie das Antwort-Caching für ein API-Gateway aktivieren können:
- Ein Cacheserver, der das RESP-Protokoll implementiert (wie Redis oder KeyDB), muss bereits eingerichtet und verfügbar sein.
- Das Subnetz des API-Gateways muss auf den Cacheserver zugreifen können.
- Der Cacheserver muss auf einem einzelnen Cacheserverhost gehostet werden und darf nicht auf mehrere Instanzen in einem Cluster verteilt werden.
- Sie müssen die Zugangsdaten für die Authentifizierung beim Cacheserver als Secret in einem Vault im Vault-Service gespeichert haben (siehe Secret in einem Vault erstellen). Außerdem müssen Sie die OCID und die Versionsnummer des Secrets kennen. Wenn Sie den Inhalt des Secrets angeben, verwenden Sie das Format
{"username":"<cache-server-username>", "password":"<cache-server-password>"}
. Beachten Sie, dass die Angabe eines Benutzernamens optional ist. Beispiel:{"password":"<cache-server-password>"}
- Sie müssen bereits eine Policy eingerichtet haben, um API-Gateways in einer dynamischen Gruppe die Berechtigung zum Zugriff auf das Secret im Vault-Service zu erteilen, das die Zugangsdaten zur Authentifizierung beim Cacheserver enthält (siehe Policy erstellen, um API-Gateways Zugriff auf Zugangsdaten zu erteilen, die als Secrets im Vault-Service gespeichert sind).
Antwort-Caching in einem API-Gateway aktivieren
Sie können das Antwort-Caching in einem API-Gateway mit der Konsole oder durch Bearbeiten einer JSON-Datei aktivieren.
Antwort-Caching mit der Konsole aktivieren und konfigurieren
So aktivieren und konfigurieren Sie Antwort-Caching für ein API-Gateway mit der Konsole:
-
Erstellen oder aktualisieren Sie ein API-Gateway mit der Konsole.
Weitere Informationen finden Sie unter API-Gateway erstellen und API-Gateway aktualisieren.
-
Wählen Sie im Dialogfeld Gateway erstellen im Abschnitt Erweiterte Optionen neben Antwort-Caching die Schaltfläche Aktivieren aus, und gehen Sie wie folgt vor:
- Geben Sie die Optionen für Cacheserver wie folgt an:
-
Host: Der Hostname des Cacheservers. Beispiel:
"cache.example.com"
. -
Portnummer: Die Portnummer auf dem Cacheserver. Beispiel:
6379
.
-
Host: Der Hostname des Cacheservers. Beispiel:
- Geben Sie die Optionen für Cacheserverzugangsdaten wie folgt an:
- Vault: Der Name des Vaults im Vault-Service, der die Zugangsdaten für die Anmeldung beim Cacheserver enthält.
- Vault Secret: Der Name des Secrets im angegebenen Vault, der die Zugangsdaten für die Anmeldung beim Cacheserver enthält.
- Vault-Secret-Versionsnummer: Die Version des zu verwendenden Secrets.
- Geben Sie die Optionen für Cacheserververbindung wie folgt an:
- SSL/TLS in Anforderungen verwenden: Gibt an, ob der Cacheserver TLS-fähig ist und daher eine sichere Verbindung zwischen dem API-Gateway und dem Cacheserver über TLS (früher SSL) eingerichtet werden soll.
- SSL/TLS-Zertifikat prüfen: Gibt an, ob das API-Gateway das TLS-(früher SSL-)Zertifikat des Cacheservers prüft. Beachten Sie, dass derzeit nur Zertifikate verifiziert werden, die von öffentlichen Zertifizierungsstellen signiert wurden.
- Verbindungstimeout: Gibt an, wie lange es dauert, bis ein Verbindungsversuch zum Cacheserver abgebrochen wird (in Millisekunden). Wenn das API-Gateway innerhalb dieser Zeit keine Verbindung zum Cacheserver herstellen kann, ruft das API-Gateway zuvor gecachte Daten nicht vom Cacheserver ab und schreibt keine neuen Daten für eine mögliche zukünftige Wiederverwendung in den Cacheserver.
- Lesetimeout: Wartezeit, bevor ein Versuch abgebrochen wird, Daten vom Cacheserver zu lesen, in Millisekunden. Wenn das API-Gateway innerhalb dieser Zeit keine Daten vom Cacheserver abrufen kann, sendet das API-Gateway stattdessen eine Anforderung an den Backend-Service.
- Sendtimeout: Gibt an, wie lange es dauert, bis ein Versuch abgebrochen wird, Daten in Millisekunden in den Cacheserver zu schreiben. Wenn das API-Gateway innerhalb dieser Zeit keine Daten an den Cacheserver senden kann, wird keine Antwort für eine mögliche zukünftige Wiederverwendung im Cache gespeichert.
- Geben Sie die Optionen für Cacheserver wie folgt an:
- Wählen Sie Erstellen oder Änderungen speichern aus, um das API-Gateway zu erstellen oder zu aktualisieren.
Antwort-Caching mit der CLI und einer JSON-Datei aktivieren und konfigurieren
So aktivieren und konfigurieren Sie Antwortcaching für ein API-Gateway mit der CLI und einer JSON-Datei:
-
Erstellen Sie mit Ihrem bevorzugten JSON-Editor eine Cachekonfigurationsdatei in folgendem Format:
{ "type" : "EXTERNAL_RESP_CACHE", "servers" : [ { "host" : "<cache-server-hostname>", "port" : <port-number> } ], "authenticationSecretId" : "<secret-ocid>", "authenticationSecretVersionNumber" : <secret-version-number>, "isSSLEnabled" : <true|false>, "isSSLVerifyDisabled" : <true|false>, "connectTimeoutInMs" : <milliseconds>, "readTimeoutInMs" : <milliseconds>, "readTimeoutInMs" : <milliseconds> }
Dabei gilt:"type" : "EXTERNAL_RESP_CACHE"
gibt an, dass das Antwort-Caching aktiviert werden soll. Wenn diese Option nicht festgelegt ist, lautet der Standardwert"type" : "NONE"
, was darauf hinweist, dass das Antwort-Caching deaktiviert ist."host" : "<cache-server-hostname>"
ist der Hostname des Cacheservers. Beispiel:"host" : "cache.example.com"
."port" : <port-number>
ist die Portnummer auf dem Cacheserver. Beispiel:"port" : 6379
."authenticationSecretId" : "<secret-ocid>"
ist die OCID des Secrets, das in einem Vault im Vault-Service definiert ist und die Zugangsdaten für die Anmeldung beim Cacheserver enthält. Beispiel:"authenticationSecretId" : "ocid.oc1.sms.secret.aaaaaa______gbdn"
"authenticationSecretVersionNumber" : <secret-version-number>
ist die Version des zu verwendenden Secrets. Zum Beispiel,"authenticationSecretVersionNumber" : 1
"isSSLEnabled" : <true|false>
gibt an, ob der Cacheserver TLS-fähig ist und daher eine sichere Verbindung zwischen dem API-Gateway und dem Cacheserver über TLS (früher SSL) eingerichtet werden soll. Wenn diese Option nicht festgelegt ist, wird standardmäßigfalse
verwendet."isSSLVerifyDisabled" : <true|false>
gibt an, ob das API-Gateway das TLS-(früher SSL-)Zertifikat des Cacheservers prüft. Beachten Sie, dass derzeit nur Zertifikate überprüft werden, die von öffentlichen Zertifizierungsstellen signiert wurden. Wenn diese Option nicht festgelegt ist, wird standardmäßigfalse
verwendet."connectTimeoutInMs" : <milliseconds>
gibt an, wie lange gewartet werden muss, bevor ein Verbindungsversuch zum Cacheserver abgebrochen wird (in Millisekunden). Wenn das API-Gateway innerhalb dieser Zeit keine Verbindung zum Cacheserver herstellen kann, ruft das API-Gateway keine zuvor gecachten Daten vom Cacheserver ab und schreibt keine neuen Daten für eine mögliche zukünftige Wiederverwendung auf den Cacheserver. Wenn dies nicht festgelegt ist, lautet der Standardwert1000
. Zum Beispiel,"connectTimeoutInMs" : 1500
"readTimeoutInMs" : <milliseconds>
gibt an, wie lange gewartet werden muss, bevor ein Versuch abgebrochen wird, Daten vom Cacheserver zu lesen, in Millisekunden. Wenn das API-Gateway innerhalb dieser Zeit keine Daten vom Cacheserver abrufen kann, sendet das API-Gateway stattdessen eine Anforderung an den Backend-Service. Wenn dies nicht festgelegt ist, lautet der Standardwert1000
. Zum Beispiel"readTimeoutInMs" : 250
"sendTimeoutInMs" : <milliseconds>
gibt an, wie lange gewartet werden muss, bevor ein Versuch, Daten auf den Cacheserver zu schreiben, in Millisekunden abgebrochen wird. Wenn das API-Gateway innerhalb dieser Zeit keine Daten an den Cacheserver senden kann, werden Antworten nicht für eine potenzielle zukünftige Wiederverwendung gecacht. Wenn dies nicht festgelegt ist, lautet der Standardwert1000
. Zum Beispiel,"sendTimeoutInMs" : 1250
Beispiel:
{ "type" : "EXTERNAL_RESP_CACHE", "servers" : [ { "host" : "cache.example.com", "port" : 6379 } ], "authenticationSecretId" : "ocid.oc1.sms.secret.aaaaaa______gbdn", "authenticationSecretVersionNumber" : 1, "isSSLEnabled" : true, "isSSLVerifyDisabled" : false, "connectTimeoutInMs" : 1000, "readTimeoutInMs" : 250, "sendTimeoutInMs" : 1000 }
- Speichern Sie die Cachekonfigurationsdatei mit einem Namen Ihrer Wahl. Zum Beispiel,
resp-cache-config.json
- Verwenden Sie die Cachekonfigurationsdatei, wenn Sie ein API-Gateway mit der CLI erstellen oder aktualisieren:
- Um ein neues API-Gateway mit aktiviertem Antwort-Caching zu erstellen, befolgen Sie die CLI-Anweisungen unter API-Gateway erstellen, und setzen Sie den Parameter
--response-cache-details
auf den Namen und den Speicherort der Cachekonfigurationsdatei. Beispiel:oci api-gateway gateway create --display-name "Hello World Gateway" --compartment-id ocid1.compartment.oc1..aaaaaaaa7______ysq --endpoint-type "PRIVATE" --subnet-id ocid1.subnet.oc1.iad.aaaaaaaaz______rca --response-cache-details file:///etc/caches/resp-cache-config.json
- Um ein vorhandenes API-Gateway zu aktualisieren, um das Antwort-Caching zu aktivieren oder die Einstellungen für das Antwort-Caching zu ändern, befolgen Sie die CLI-Anweisungen unter API-Gateway aktualisieren, und setzen Sie den Parameter
--response-cache-details
auf den Namen und den Speicherort der Cachekonfigurationsdatei. Beispiel:oci api-gateway gateway update --gateway-id ocid1.apigateway.oc1..aaaaaaaab______hga --response-cache-details file:///etc/caches/resp-cache-config.json
- Um ein neues API-Gateway mit aktiviertem Antwort-Caching zu erstellen, befolgen Sie die CLI-Anweisungen unter API-Gateway erstellen, und setzen Sie den Parameter
Antwort-Caching-Anforderungs- und -Antwort-Policys hinzufügen
Sie können Antwort-Caching-Anforderungen und Antwort-Policys zu API-Deploymentspezifikationen hinzufügen, indem Sie die Konsole verwenden oder eine JSON-Datei bearbeiten. Beachten Sie, dass Sie das Antwort-Caching in einem API-Gateway aktivieren müssen, damit die Anforderungs- und Antwort-Policys wirksam werden.
Antwort-Caching-Anforderung und -Antwort-Policys mit der Konsole hinzufügen
So fügen Sie mit der Konsole Antwort-Caching-Anforderungs- und Antwort-Policys zu einer API-Deployment-Spezifikation hinzu:
-
Erstellen oder aktualisieren Sie ein API-Deployment mit der Konsole, wählen Sie die Option Völlig neu aus, und geben Sie auf der Seite Basisinformationen Details ein.
Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployment in einem API-Gateway bereitstellen und API-Gateway aktualisieren.
-
Wählen Sie Weiter aus, um Details zu einzelnen Routen im API-Deployment auf der Seite Routen einzugeben, und wählen Sie Antwort-Caching aus.
- Wählen Sie die Option Caching für diese Route aus, und geben Sie die Antwort-Caching-Optionen an, die für diese bestimmte Route gelten:
- TTL (Gültigkeitsdauer) für gecachte Antworten in Sekunden: Wie lange gecachte Daten auf dem Cacheserver für diese bestimmte Route verfügbar sind.
- Schlüsselhinzufügungen cachen: Eine oder mehrere Kontextvariablen, die dem Standardcacheschlüssel hinzugefügt werden sollen, um eine gecachte Antwort enger mit einer bestimmten Anforderung zu verknüpfen. Beispiel:
request.headers[X-Username]
. Sie können aus einer Liste häufig verwendeter Kontextvariablen auswählen oder eine Kontextvariable Ihrer Wahl eingeben. Stellen Sie der Kontextvariablen kein Symbol "$" voran, oder setzen Sie sie in geschweifte Klammern (wie beim Hinzufügen der Kontextvariable zu einer URL in einer API-Deployment-Spezifikation in einer JSON-Datei). Weitere Informationen finden Sie unter Hinweise zum Anpassen von Cacheschlüsseln.
- Wenn Sie Antworten für Anforderungen cachen möchten, die einen Autorisierungsheader enthalten oder einen Header oder Abfrageparameter enthalten, der in einer Authentifizierungs-Policy identifiziert ist, wählen Sie die Option Antworten mit Autorisierungsheadern cachen.
Beachten Sie, dass das Caching von Antworten für solche Anforderungen die Datensicherheit beeinträchtigen kann. Weitere Informationen finden Sie unter Hinweise zum Caching von Antworten für Anforderungen mit Zugangsdaten (privates Caching).
- Wählen Sie Weiter aus, um die Details zu prüfen, die Sie für das API-Deployment eingegeben haben.
- Wählen Sie Erstellen oder Änderungen speichern aus, um das API-Deployment zu erstellen oder zu aktualisieren.
- (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).
Antwort-Caching-Anforderungs- und -Antwort-Policys durch Bearbeiten einer JSON-Datei hinzufügen
Um einer bestimmten Route Antwort-Caching hinzuzufügen, müssen Sie sowohl eine Anforderungs-Policy als auch eine Antwort-Policy hinzufügen.
So fügen Sie die Antwort-Caching-Anforderung und Antwort-Policy zu einer API-Deployment-Spezifikation in einer JSON-Datei hinzu:
-
Bearbeiten Sie mit Ihrem bevorzugten JSON-Editor die vorhandene API-Deployment-Spezifikation, der Sie Antwort-Caching hinzufügen möchten, oder erstellen Sie eine neue API-Deployment-Spezifikation (siehe API-Deployment-Spezifikation erstellen).
Beispiel: Die folgende Basisspezifikation für das API-Deployment definiert eine einfache serverlose Hello World-Funktion in OCI Functions als einzelnes Backend:
{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
So geben Sie die Antwort-Caching-Anforderung und Antwort-Policy an, die für eine einzelne Route gilt:
-
Fügen Sie nach dem Backend-Abschnitt für die Route, auf die Sie die Policy anwenden möchten, sowohl einen
requestPolicies
-Abschnitt als auch einenresponsePolicies
-Abschnitt ein. Beispiel:{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" }, "requestPolicies": {}, "responsePolicies": {} } ] }
- Fügen Sie die folgende
responseCacheLookup
-Anforderungs-Policy zum neuenrequestPolicies
-Bereich hinzu, um sie auf die Route anzuwenden:{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" }, "requestPolicies": { "responseCacheLookup": { "type": "SIMPLE_LOOKUP_POLICY", "isEnabled": true, "isPrivateCachingEnabled": <true|false>, "cacheKeyAdditions": [<list-of-context-variables>] } }, "responsePolicies": {} } ] }
Dabei gilt:
"type": "SIMPLE_LOOKUP_POLICY"
ist der Typ des zu implementierenden Antwortcachings. Nur"SIMPLE_LOOKUP_POLICY"
wird derzeit unterstützt."isEnabled": true
gibt an, dass das Antwort-Caching für die Route aktiviert ist. Wenn Sie das Antwort-Caching vorübergehend deaktivieren möchten, setzen Sie"isEnabled": false
. Wenn kein Wert angegeben wird, wird standardmäßigtrue
verwendet."isPrivateCachingEnabled": <true|false>
gibt an, ob Antworten für Anforderungen gecacht werden sollen, die einen Autorisierungsheader enthalten oder einen Header oder Abfrageparameter enthalten, der in einer Authentifizierungs-Policy identifiziert wird. Beachten Sie, dass das Caching von Antworten für solche Anforderungen die Datensicherheit beeinträchtigen kann. Wenn keine Angabe gemacht wird, lautet der Standardwertfalse
, der angibt, dass Antworten für solche Anforderungen nicht im Cache gespeichert werden. Weitere Informationen finden Sie unter Hinweise zum Caching von Antworten für Anforderungen mit Zugangsdaten (privates Caching)."cacheKeyAdditions": [<list-of-context-variables>]
ist eine optionale kommagetrennte Liste von Kontextvariablen, die dem Standardcacheschlüssel hinzugefügt werden, um eine gecachte Antwort enger mit einer bestimmten Anforderung zu verknüpfen. Beispiel:"cacheKeyAdditions": ["request.headers[Accept]"]
. Stellen Sie der Kontextvariablen kein $-Symbol voran, oder setzen Sie sie in geschweifte Klammern (wie Sie es tun würden, wenn Sie die Kontextvariable zu einer URL in einer API-Deployment-Spezifikation in einer JSON-Datei hinzufügen würden). Weitere Informationen finden Sie unter Hinweise zum Anpassen von Cacheschlüsseln.
- Fügen Sie die folgende
responseCacheStorage
-Antwort-Policy zum neuenresponsePolicies
-Abschnitt hinzu, der auf die Route angewendet werden soll:{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" }, "requestPolicies": { "responseCacheLookup": { "type": "SIMPLE_LOOKUP_POLICY", "isEnabled": true, "isPrivateCachingEnabled": false, "cacheKeyAdditions": ["request.headers[Accept]"] } }, "responsePolicies": { "responseCacheStorage": { "type": "FIXED_TTL_STORE_POLICY", "timeToLiveInSeconds": <seconds> } } } ] }
Dabei gilt:
"type": "FIXED_TTL_STORE_POLICY"
ist der Typ des Antwortcaches, in dem Antworten gespeichert werden. Nur"FIXED_TTL_STORE_POLICY"
wird derzeit unterstützt."timeToLiveInSeconds": <seconds>
gibt an, wie lange zwischengespeicherte Daten auf dem Cacheserver für diese bestimmte Route verfügbar sind. Beispiel:"timeToLiveInSeconds": 300
Beispiel:
{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" }, "requestPolicies": { "responseCacheLookup": { "type": "SIMPLE_LOOKUP_POLICY", "isEnabled": true, "isPrivateCachingEnabled": false, "cacheKeyAdditions": ["request.headers[Accept]"] } }, "responsePolicies": { "responseCacheStorage": { "type":"FIXED_TTL_STORE_POLICY", "timeToLiveInSeconds": 300 } } } ] }
-
- Speichern Sie die JSON-Datei, die die API-Deployment-Spezifikation enthält.
-
Verwenden Sie die API-Deployment-Spezifikation, wenn Sie ein API-Deployment wie folgt erstellen oder aktualisieren:
- Durch Angabe der JSON-Datei in der Konsole bei Auswahl der Option Vorhandene API hochladen
- Durch Angabe der JSON-Datei in einer Anforderung an die REST-API von API-Gateway
Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployment in einem API-Gateway bereitstellen und API-Gateway aktualisieren.
- (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).