Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
Über die OASValidation-Richtlinie
Mit der OASValidation-Richtlinie (OpenAPI-Spezifikation) können Sie eine eingehende Anfrage oder Antwortnachricht mit einer OpenAPI 3.0-Spezifikation (JSON oder YAML) prüfen. Siehe Welche Inhalte werden validiert?
Die OASValidation-Richtlinie gibt den Namen der OpenAPI-Spezifikation an, die für die Validierung verwendet werden soll, wenn der Schritt, mit dem die Richtlinie verknüpft ist, ausgeführt wird.
Die OpenAPI-Spezifikation wird als Ressource im folgenden Standardspeicherort im API-Proxy-Bundle gespeichert: apiproxy/resources/oas
.
Das OpenAPI-Spezifikationsdokument muss die Erweiterung .json
, .yml
oder .yaml
haben.
Fügen Sie einem API-Proxy-Bundle mithilfe der UI oder API eine OpenAPI-Spezifikation als Ressource hinzu, wie unter Ressourcen verwalten beschrieben.
Diese Richtlinie ist eine Standardrichtlinie, die in jeder Umgebung bereitgestellt werden kann. Informationen zu Richtlinientypen und zur Verfügbarkeit bei jedem Umgebungstyp finden Sie unter Richtlinientypen.
Welche Inhalte werden validiert?
Die folgende Tabelle fasst den Nachrichteninhalt der Anfrage, die von der OASValidation-Richtlinie validiert wird, nach Komponente zusammen.
Komponenten | Anfragevalidierung |
---|---|
Basispfad | Validiert den vom API-Proxy definierten Basispfad und ignoriert den in der OpenAPI-Spezifikation angegebenen Basispfad. |
Pfad | Validiert, dass der Anfragepfad (ohne den Basispfad) mit einem der in der OpenAPI-Spezifikation definierten Pfadmuster übereinstimmt. |
Verb | Validiert, dass das Verb für den Pfad in der OpenAPI-Spezifikation definiert ist. |
Nachrichtentext der Anfrage |
Hinweis: Die Richtlinie validiert den Nachrichtentext der Anfrage anhand der OpenAPI-Spezifikation nur dann, wenn der Inhaltstyp auf |
Parameter |
|
Die folgende Tabelle fasst den Nachrichteninhalt der Antwort, die von der OASValidation-Richtlinie validiert wird, nach Komponente zusammen.
Komponenten | Antwortenvalidierung |
---|---|
Pfad | Validiert, dass der Anfragepfad (ohne den Basispfad) mit einem der in der OpenAPI-Spezifikation definierten Pfadmuster übereinstimmt. |
Verb | Validiert, dass das Verb für den Pfad in der OpenAPI-Spezifikation definiert ist. |
Nachrichtentext der Antwort |
|
Beispiele
Folgende Beispiele zeigen einige Möglichkeiten, wie Sie die OASValidation-Richtlinie verwenden können, um Nachrichten anhand einer OpenAPI 3.0-Spezifikation zu prüfen.
Anfragenachricht validieren
Im folgenden Beispiel prüft die myoaspolicy
-Richtlinie den Text der Anfragenachricht anhand des Nachrichtentextschemas der Anfrage des Vorgangs, das in der my-spec.json
-OpenAPI-Spezifikation definiert ist.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.json</OASResource> <Options> <ValidateMessageBody>true</ValidateMessageBody> </Options> <Source>request</Source> </OASValidation>
Stimmt der Nachrichtentext nicht mit der OpenAPI-Spezifikation überein, so wird ein policies.oasvalidation.Failed
-Fehler zurückgegeben.
Parameter validieren
Im folgenden Beispiel wird die Richtlinie so konfiguriert, dass sie fehlschlägt, falls ein Header, eine Abfrage oder ein Cookie-Parameter in der Anfrage angegeben wird, der in der OpenAPI-Spezifikation nicht definiert ist.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <AllowUnspecifiedParameters> <Header>false</Header> <Query>false</Query> <Cookie>false</Cookie> </AllowUnspecifiedParameters> </Options> </OASValidation>
Element <OASValidation>
Definiert die OASValidation-Richtlinie (OpenAPI Specification Validation).
Standardwert | Siehe unten, Tab Standardrichtlinie |
Erforderlich? | Erforderlich |
Typ | Komplexes Objekt |
Übergeordnetes Element | – |
Untergeordnete Elemente |
<DisplayName> <OASResource> <Source> <Options> <Source> |
Syntax
Das <OASValidation>
-Element verwendet die folgende Syntax:
<OASValidation continueOnError="[true|false]" enabled="[true|false]" name="policy_name" > <!-- All OASValidation child elements are optional except OASResource --> <DisplayName>policy_display_name</DisplayName> <OASResource>validation_JSON_or_YAML</OASResource> <Options> <ValidateMessageBody>[true|false]</ValidateMessageBody> <AllowUnspecifiedParameters> <Header>[true|false]</Header> <Query>[true|false]</Query> <Cookie>[true|false]</Cookie> </AllowUnspecifiedParameters> </Options> <Source>message_to_validate</Source> </OASValidation>
Standardrichtlinie
Das folgende Beispiel zeigt die Standardeinstellungen, wenn Sie in der Apigee-UI Ihrem Ablauf eine OASValidation-Richtlinie hinzufügen:
<OASValidation continueOnError="false" enabled="true" name="OpenAPI-Spec-Validation-1"> <DisplayName>OpenAPI Spec Validation-1</DisplayName> <Properties/> <Source>request</Source> <OASResource>oas://OpenAPI-Spec-Validation-1.yaml</OASResource> </OASValidation>
Dieses Element hat folgende Attribute, die allen Richtlinien gemeinsam sind:
Attribut | Standard | Erforderlich? | Beschreibung |
---|---|---|---|
name |
- | Erforderlich |
Der interne Name der Richtlinie. Der Wert des Attributs Optional können Sie das Element |
continueOnError |
false | Optional | Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten. Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird. Weitere Informationen:
|
enabled |
wahr | Optional | Setzen Sie den Wert auf true , um die Richtlinie zu erzwingen. Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht durchgesetzt, selbst wenn sie mit einem Ablauf verknüpft ist. |
async |
false | Verworfen | Dieses Attribut wurde verworfen. |
Verweis auf untergeordnetes Element
In diesem Abschnitt werden die untergeordneten Elemente von <OASValidation>
beschrieben.
<DisplayName>
Wird zusätzlich zum Attribut name
verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen, natürlicher klingenden Namen zu versehen.
Das Element <DisplayName>
ist für alle Richtlinien gleich.
Standardwert | – |
Erforderlich? | Optional. Wenn Sie <DisplayName> weglassen, wird der Wert des Attributs name der Richtlinie verwendet. |
Typ | String |
Übergeordnetes Element | <PolicyElement> |
Untergeordnete Elemente | Keine |
Das <DisplayName>
-Element verwendet die folgende Syntax:
Syntax
<PolicyElement> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> ... </PolicyElement>
Beispiel
<PolicyElement> <DisplayName>My Validation Policy</DisplayName> </PolicyElement>
Das <DisplayName>
-Element hat keine Attribute oder untergeordneten Elemente.
<OASResource>
Gibt die OpenAPI-Spezifikation an, gegen die validiert werden soll. Sie können diese Datei speichern:
- Im API-Proxy-Bereich unter
/apiproxy/resources/oas
im API-Proxy-Bundle - Im Abschnitt
Resources
der Navigatoransicht des API-Proxy-Editors.
Weitere Informationen finden Sie unter Ressourcen verwalten.
Sie können die OpenAPI-Spezifikation mithilfe einer Nachrichtenvorlage angeben, beispielsweise {oas.resource.url}
.
In diesem Fall wird der Wert der Flussvariablen oas.resource.url
(in geschweiften Klammern) ausgewertet und zur Laufzeit durch den Nutzlaststring ersetzt.
Weitere Informationen finden Sie unter SMS-Vorlagen.
Standardwert | – |
Erforderlich? | Erforderlich |
Typ | String |
Übergeordnetes Element |
<OASValidation>
|
Untergeordnete Elemente | Keine |
Syntax
Das <OASResource>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> ... </OASValidation>
Beispiel
Folgendes Beispiel verweist auf die Spezifikation my-spec.yaml
, die unter /apiproxy/resources/oas
im API-Proxy-Bundle gespeichert ist:
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> </OASValidation>
Das <OASResource>
-Element hat keine Attribute oder untergeordneten Elemente.
<Options>
Konfiguriert Optionen für die Richtlinie.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplexer Typ |
Übergeordnetes Element |
<OASValidation>
|
Untergeordnete Elemente |
<ValidateMessageBody> <AllowUnspecifiedParameters> |
Syntax
Das <Options>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Options> <ValidateMessageBody>[true|false]</ValidateMessageBody> <AllowUnspecifiedParameters> <Header>[true|false]</Header> <Query>[true|false]</Query> <Cookie>[true|false]</Cookie> </AllowUnspecifiedParameters> </Options> ... </OASValidation>
Beispiel
Im folgenden Beispiel werden die Optionen für die Richtlinie konfiguriert. Jede dieser Optionen wird im Folgenden näher beschrieben.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <ValidateMessageBody>false</ValidateMessageBody> <AllowUnspecifiedParameters> <Header>false</Header> <Query>false</Query> <Cookie>false</Cookie> </AllowUnspecifiedParameters> </Options> </OASValidation>
<ValidateMessageBody>
Gibt an, ob der Richtlinientext in der OpenAPI-Spezifikation mit dem Anfragetexttext des Vorgangs abgeglichen werden soll. Setzen Sie diesen Wert auf true, um den Inhalt des Nachrichteninhalts zu validieren. Setzen Sie diesen Wert auf false, um nur zu prüfen, ob der Nachrichtentext vorhanden ist.
Sie können festlegen, ob der Ablauf nach einem Validierungsfehler weiterhin ausgeführt wird. Setzen Sie dazu das Attribut continueOnError
für das Element <OASValidation>
auf true.
Standardwert | false |
Erforderlich? | Optional |
Typ | Boolesch |
Übergeordnetes Element |
<Options>
|
Untergeordnete Elemente | Keine |
Syntax
Das <ValidateMessageBody>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Options> <ValidateMessageBody>[true|false]</ValidateMessageBody> </Options> ... </OASValidation>
Beispiel
Im folgenden Beispiel wird die Validierung des Nachrichtentexts aktiviert:
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <ValidateMessageBody>true</ValidateMessageBody> </Options> </OASValidation>
<AllowUnspecifiedParameters>
Konfiguriert das Verhalten der Richtlinie, wenn die Anfrage Header-, Abfrage- oder Cookie-Parameter enthält, die nicht in der OpenAPI-Spezifikation definiert sind.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplexer Typ |
Übergeordnetes Element |
<Options>
|
Untergeordnete Elemente |
<Header> <Query> <Cookie> |
Syntax
Das <AllowUnspecifiedParameters>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Options> <AllowUnspecifiedParameters> <Header>[true|false]</Header> <Query>[true|false]</Query> <Cookie>[true|false]</Cookie> </AllowUnspecifiedParameters> </Options> ... </OASValidation>
Beispiel
Im folgenden Beispiel wird die Richtlinie so konfiguriert, dass sie fehlschlägt, falls ein Header, eine Abfrage oder ein Cookie-Parameter in der Anfrage angegeben wird, der in der OpenAPI-Spezifikation nicht definiert ist.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <AllowUnspecifiedParameters> <Header>false</Header> <Query>false</Query> <Cookie>false</Cookie> </AllowUnspecifiedParameters> </Options> </OASValidation>
<Header>
(<AllowUnspecifiedParameters>
untergeordnet)
Konfiguriert das Verhalten der Richtlinie, wenn in der Anfrage Headerparameter vorhanden sind, die nicht in der OpenAPI-Spezifikation definiert sind.
Damit Headerparameter in der Anfrage angegeben werden können, die nicht in der OpenAPI-Spezifikation definiert sind, setzen Sie diesen Parameter auf true. Setzen Sie andernfalls diesen Parameter auf false, damit die Richtlinienausführung fehlschlägt.
Standardwert | true |
Erforderlich? | Boolesch |
Typ | Komplexer Typ |
Übergeordnetes Element |
<AllowUnspecifiedParameters>
|
Untergeordnete Elemente | Keine |
Syntax
Das <Header>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Options> <AllowUnspecifiedParameters> <Header>[true|false]</Header> </AllowUnspecifiedParameters> </Options> ... </OASValidation>
Beispiel
Im folgenden Beispiel wird die Richtlinie so konfiguriert, dass ein Headerparameter in der Anfrage angegeben wird, der nicht in der OpenAPI-Spezifikation definiert ist.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <AllowUnspecifiedParameters> <Header>false</Header> </AllowUnspecifiedParameters> </Options> </OASValidation>
<Query>
(<AllowUnspecifiedParameters>
untergeordnet)
Konfiguriert das Verhalten der Richtlinie für den Fall, dass die Anfrage Abfrageparameter enthält, die nicht in der OpenAPI-Spezifikation definiert sind.
Damit Abfrageparameter in der Anfrage angegeben werden können, die nicht in der OpenAPI-Spezifikation definiert sind, setzen Sie diesen Parameter auf true. Setzen Sie andernfalls diesen Parameter auf false, damit die Richtlinienausführung fehlschlägt.
Standardwert | true |
Erforderlich? | Boolesch |
Typ | Komplexer Typ |
Übergeordnetes Element |
<AllowUnspecifiedParameters>
|
Untergeordnete Elemente | Keine |
Syntax
Das <Query>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Options> <AllowUnspecifiedParameters> <Query>[true|false]</Query> </AllowUnspecifiedParameters> </Options> ... </OASValidation>
Beispiel
Im folgenden Beispiel wird die Richtlinie so konfiguriert, dass ein Abfrageparameter in der Anfrage angegeben wird, der nicht in der OpenAPI-Spezifikation definiert ist.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <AllowUnspecifiedParameters> <Query>false</Query> </AllowUnspecifiedParameters> </Options> </OASValidation>
Konfiguriert das Verhalten der Richtlinie für den Fall, dass die Anfrage Cookieparameter enthält, die nicht in der OpenAPI-Spezifikation definiert sind.
Damit Cookieparameter in der Anfrage angegeben werden können, die nicht in der OpenAPI-Spezifikation definiert sind, setzen Sie diesen Parameter auf true. Setzen Sie andernfalls diesen Parameter auf false, damit die Richtlinienausführung fehlschlägt.
Standardwert | true |
Erforderlich? | Boolesch |
Typ | Komplexer Typ |
Übergeordnetes Element |
<AllowUnspecifiedParameters>
|
Untergeordnete Elemente | Keine |
Syntax
Das <Cookie>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Options> <AllowUnspecifiedParameters> <Query>[true|false]</Query> </AllowUnspecifiedParameters> </Options> ... </OASValidation>
Beispiel
Im folgenden Beispiel wird die Richtlinie so konfiguriert, dass ein Abfrageparameter in der Anfrage angegeben wird, der nicht in der OpenAPI-Spezifikation definiert ist.
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Options> <AllowUnspecifiedParameters> <Cookie>false</Cookie> </AllowUnspecifiedParameters> </Options> </OASValidation>
<Source>
JSON-Nachricht, die im Hinblick auf Angriffe über JSON-Nutzlasten ausgewertet werden soll. Dies ist meistens auf request
gesetzt, da Sie in der Regel eingehende Anfragen von Client-Apps evaluieren müssen.
Durch die Einstellung auf response werden Antwortnachrichten bewertet.
Durch die Einstellung auf message wird automatisch die Anfragenachricht bewertet, wenn die Richtlinie an den Anfrageablauf angehängt wird. Wenn die Richtlinie an den Antwortablauf angehängt wird, wird bei dieser Einstellung automatisch die Antwortnachricht bewertet.
Standardwert | Anfrage |
Erforderlich? | Optional |
Typ | String |
Übergeordnetes Element |
<Source>
|
Untergeordnete Elemente | Keine |
Syntax
Das <Source>
-Element verwendet die folgende Syntax:
<OASValidation name="policy_name"> <OASResource>oas://specname[.json|.yaml|.yml]</OASResource> <Source>[message|request|response]</Source> ... </OASValidation>
Beispiel
Im folgenden Beispiel wird die Anfragenachricht automatisch ausgewertet, wenn die Richtlinie an den Anfrageablauf angehängt wird, und wenn die Richtlinie an den Antwortablauf angehängt wird, wird die Antwortnachricht ausgewertet:
<OASValidation name="myoaspolicy"> <OASResource>oas://my-spec.yaml</OASResource> <Source>message</Source> </OASValidation>
Das <Source>
-Element hat keine Attribute oder untergeordneten Elemente.
Schema für diese Richtlinie
Jeder Richtlinientyp wird durch ein XML-Schema (.xsd
) definiert. Zu Referenzzwecken sind Richtlinienschemas auf GitHub verfügbar.
Fehlercodes
In diesem Abschnitt werden die zurückgegebenen Fehlercodes und Fehlermeldungen beschrieben, die von Apigee festgelegt werden, wenn die Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.
Laufzeitfehler
Diese Fehler können bei Ausführung der Richtlinie auftreten.
Fehlercode | HTTP-Status | Ursache |
---|---|---|
steps.oasvalidation.Failed |
400 |
Der Text der Anfragenachricht kann nicht mit der bereitgestellten OpenAPI-Spezifikation validiert werden. |
steps.oasvalidation.Failed |
500 |
Der Text der Antwortnachricht kann nicht mit der bereitgestellten OpenAPI-Spezifikation validiert werden. |
steps.oasvalidation.SourceMessageNotAvailable |
500 |
Die im Element |
steps.oasvalidation.NonMessageVariable |
500 |
Für das |
Bereitstellungsfehler
Diese Fehler können auftreten, wenn Sie einen Proxy mit dieser Richtlinie bereitstellen.
Fehlername | Ursache | |
---|---|---|
ResourceDoesNotExist |
Die im Element <OASResource> referenzierte OpenAPI-Spezifikation ist nicht vorhanden. |
|
ResourceCompileFailed |
Die in der Bereitstellung enthaltene OpenAPI-Spezifikation enthält Fehler, die verhindern, dass sie kompiliert werden. Dies weist im Allgemeinen darauf hin, dass die Spezifikation keine korrekt formatierte OpenAPI-Spezifikation 3.0 darstellt. | |
BadResourceURL |
Die im Element <OASResource> angegebene OpenAPI-Spezifikation kann nicht verarbeitet werden. Dieser Fehler kann auftreten, wenn die Datei keine JSON- oder YAML-Datei ist oder die Datei-URL nicht korrekt angegeben wurde.
|
Fehlervariablen
Diese Variablen werden festgelegt, wenn diese Richtlinie zur Laufzeit einen Fehler auslöst. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.
Variable | Beschreibung | Beispiel |
---|---|---|
fault.category |
Die Fehlerkategorie. Wenn die Richtlinie einen Antrag ablehnt, gilt dies immer für Step . |
fault.category = "Step" |
fault.name |
Der Name des Fehlers, wie er in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. | fault.name Matches "ResourceDoesNotExist" |
fault.reason |
Die Ursache des Fehlers. Es ist ein für Menschen lesbarer String, der den Grund für den Fehler erläutert. | OASValidation OAS-1 with resource "oas://my-spec1.yaml": failed with reason: "[ERROR - POST operation not allowed on path '/persons/13'.: []]" |
fault.subcategory |
Die Unterkategorie des Fehlers. Wenn die Richtlinie einen Antrag ablehnt, gilt dies immer für OASValidationFailure . |
fault.subcategory = "OASValidationFailure" |
OASValidation.policy_name.failed |
policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. | OASValidation.myoaspolicy.failed = true |
Unterstützte OpenAPI-Spezifikationsfeatures
Die OASValidation-Richtlinie unterstützt die OpenAPI-Spezifikationsfeatures, die in der folgenden Tabelle nach Kategorie zusammengefasst sind. Die nicht unterstützten Features sind ebenfalls aufgelistet.
Kategorie | Unterstützt | Nicht unterstützt |
---|---|---|
Datentypformate | boolean date date-time double float int32/int64 ipv4/ipv6 md5 sha1/sha256/sha512 string uri uri-template uuid |
binary byte password |
Diskriminator-Objekt | mapping propertyName |
– |
Medientypobjekt | schema | encoding example examples |
Vorgangsobjekt | parameters requestBody responses security (partial support) |
callbacks deprecated servers |
Parameterobjekt | allowEmptyValue in ( query , header , path )required responses schema style ( deepObject , form , formmatrix , label , pipeDelimited , simple , spaceDelimited )Hinweis: deepObject unterstützt nur Stringparameter. Arrays und verschachtelte Objekte werden nicht unterstützt. |
allowReserved deprecated example examples content |
Pfadobjekt | delete get head options parameters patch post put trace variables |
Server |
Anfragetextobjekt | application/json application/hal+json application/x-www-form-urlencoded ( encoding -Objekt wird nicht unterstützt)content required |
application/xml multipart/form-data text/plain text/xml |
Antwortobjekt | application/json application/hal+json application/x-www-form-urlencoded ( encoding -Objekt wird nicht unterstützt)content headers |
application/xml links text/plain text/xml |
Antwortenobjekt | default HTTP-Statuscode |
– |
Schema-Objekt | $ref additionalProperties (nur boolesche Flagvariante) allOf (wird ignoriert, wenn additionalProperties false ist)anyOf enum exclusiveMaximum/exclusiveMinimum format items maximum/minimum maxItems/minItems maxLength/minLength maxProperties/minProperties multipleOf not nullable oneOf pattern properties required title type uniqueItems |
deprecated example readOnly writeOnly xml |
Sicherheitsschema-Objekt | in (header , query ) (wird ignored, wenn type http ist)name type ( apiKey , http )
|
bearerFormat flows openIdConnectUrl scheme |
Serverobjekt | url variables |
Mehrere Serverdefinitionen |
Muster im Schema verwenden
Der OpenAPI-Spezifikationsstandard ermöglicht die Angabe eines schema
zur Beschreibung des Datentyps eines Parameters oder Felds. Für einen Parameter oder ein Feld vom Typ „String" kann das Schema auch eine pattern
definieren. Dabei handelt es sich um einen regulären Ausdruck (Regex), der gültige Formen für den String definiert.
Sehen Sie sich als Beispiel das folgende OpenAPI-Spezifikationsfragment an:
paths: /products/{product-id}: get: operationId: getProduct summary: Get product by id description: returns information regarding a product, by id parameters: - name: product-id in: path description: id of the product required: true schema: type: string pattern: '^\w{3}-\d{4}$'
Diese Spezifikation erfordert, dass für den getProduct
-Vorgang der Parameter product-id
dem angegebenen regulären Ausdruck entsprechen muss, der eine Sequenz aus 3 Wortzeichen, einen Bindestrich und 4 Dezimalstellen festlegt.
Die OpenAPI-Spezifikation verweist auf den JSON-Schemavalidierungsstandard, um das Verhalten des Musters bei der Validierung des Stringwerts formal zu definieren, und auf den JSON Schema Core-Standard, um Empfehlungen für Schemaautoren bezüglich der eingeschränkten Syntax regulärer Ausdrücke zu geben. Dieser letztere Standard empfiehlt, in Mustern in OpenAPI-Spezifikationsdokumenten u. a. die Verwendung von Lookarounds (Lookaheads und Lookbehinds), Rückverweisen und oktalen Zeichenausdrücken zu vermeiden.
Standardmäßig validiert Apigee das OpenAPI-Spezifikationsdokument, auf das die OASValidation-Richtlinie verweist, und meldet Fehler, wenn das Spezifikationsdokument nicht korrekt formatiert ist. Apigee validiert auch Regex-Muster in Ihrem Spezifikationsdokument und meldet dort gefundene Probleme.
Wenn Sie Regex-Funktionen außerhalb der empfohlenen Teilmenge verwenden, wird Apigee den regulären Ausdruck nicht validieren und jede zusätzliche Validierung Ihres OpenAPI-Spezifikationsdokuments sperren. Wenn ein Fehler im Dokument oder im Regex vorhanden ist, der eine Funktion außerhalb der empfohlenen Teilmenge verwendet, oder wenn die Regex-Funktion von der Apigee-Laufzeit nicht unterstützt wird, wird der Fehler nur zur Laufzeit erkannt, wenn wird die Richtlinie ausgeführt.
Die folgende Tabelle enthält einige Beispiele.
Muster | Verhalten |
---|---|
^\w{3}-\d{4}$ |
Das Muster ist gültig. Sie verwendet nur Regex-Funktionen innerhalb der empfohlenen Teilmenge. Apigee ermöglicht das Speichern oder Importieren des Proxys. Zur Laufzeit funktioniert die OASValidation-Richtlinie wie beabsichtigt und validiert den Parameter anhand des Musters. |
^([a-z]\w{3}-\d{4}$ |
Das Muster ist ungültig. In dieser Zeile fehlt eine schließende Klammer. Das Muster verwendet keine Regex-Funktionen außerhalb der empfohlenen Teilmenge. Apigee meldet diesen Fehler beim Importieren oder Speichern des API-Proxys. |
^(?![a-z]\w{3}-\d{4}$ |
Das Muster ist ungültig. Wie im vorherigen Beispiel fehlt hier eine schließende Klammer. Apigee meldet diesen Fehler jedoch nicht beim Speichern oder Importieren Ihres API-Proxys, da der Regex einen negativen Lookahead verwendet, was außerhalb der empfohlenen Teilmenge der Regex-Features liegt. Der Fehler wird nur zur Laufzeit erkannt, wenn die Richtlinie ausgeführt wird. |
^(?![a-z])\w{3}-\d{4}$ |
Das Muster ist gültig, verwendet jedoch einen negativen Lookahead, der außerhalb der empfohlenen Teilmenge der Regex-Funktionen liegt. Apigee sperrt die Validierung des OpenAPI-Spezifikationsdokuments. Wenn Sie zur Laufzeit die OASValidation-Richtlinie ausführen, die mit diesem Muster auf eine Spezifikation verweist, da die Apigee-Laufzeit tatsächlich negative Lookaheads unterstützt, wendet Apigee diesen regulären Ausdruck korrekt an, um den Parameterwert zu validieren. |
^(a)?b(?(1)c|d)$ |
Das Muster ist gültig, verwendet jedoch eine Erfassungsgruppenbedingung, die außerhalb der empfohlenen Teilmenge von Regex-Features liegt. Apigee sperrt die Validierung des OpenAPI-Spezifikationsdokuments. Wenn Sie zur Laufzeit die OASValidation-Richtlinie ausführen, die auf eine Spezifikation mit diesem Muster verweist, da die Apigee-Laufzeit diese Regex-Funktion nicht unterstützt, gibt Apigee einen Fehler zurück. |
Wir empfehlen, nur die empfohlene Teilmenge von Funktionen in Ihrem regulären Ausdruck zu verwenden, um Laufzeitfehler zu vermeiden.