Funktionseinschränkungen bei OpenAPI 3.x
In diesem Dokument werden die Einschränkungen bei der Verwendung von OpenAPI 3.x mit API Gateway beschrieben.
Weitere Informationen zu unterstützten OpenAPI-Spezifikationsversionen finden Sie unter Übersicht über OpenAPI.
Neue Einschränkungen für OpenAPI 3.x
In diesem Abschnitt werden Einschränkungen für neue Funktionen in OpenAPI 3.x beschrieben.
Server
OpenAPI 3.x unterstützt mehrere server-Objekte zum Definieren von Hosts und Basispfaden. API Gateway verwendet jedoch ein einzelnes Serverobjekt, das durch die Erweiterung x-google-endpoint identifiziert wird, um den Dienst zu konfigurieren.
Sie können zwar mehrere Server definieren, API Gateway berücksichtigt jedoch nur den Server, der die Erweiterung x-google-endpoint enthält, und lässt nur einen solchen Server zu. Für API Gateway ist keine Server-URL erforderlich. Sie können also entweder keine Server oder einen Server mit der Erweiterung x-google-endpoint definieren.
Die folgenden Definitionen sind beispielsweise gültig für API Gateway:
servers:
- url: https://example.com
x-google-endpoint: {}
servers:
- url: https://example.com
x-google-endpoint: {}
- url: https://example2.com
Die folgende Definition ist ungültig, da sie mehrere x-google-endpoint-Erweiterungen enthält:
servers:
- url: https://example.com
x-google-endpoint: {}
- url: https://example2.com
x-google-endpoint: {}
Die folgende Definition ist für API Gateway gültig, aber API Gateway ignoriert das Serverobjekt:
servers:
- url: https://example.com
Server in mehreren Dateien
Wenn Sie mehrere OpenAPI-Dateien hochladen und eine Datei einen Server mit der Erweiterung x-google-endpoint enthält, müssen alle Dateien auch einen Server mit einer identischen x-google-endpoint-Erweiterung und einem identischen Host in der Server-URL enthalten. Der Basispfad kann sich je nach Datei unterscheiden.
Relative URL
Bei API Gateway werden relative URLs im servers-Objekt als eigener Basispfad behandelt, da in der Spezifikation kein Hostname erforderlich ist. Das unterscheidet sich vom Standardverhalten von OpenAPI, bei dem relative URLs anhand des Servers aufgelöst werden, auf dem die OpenAPI-Definition gehostet wird. API Gateway behandelt url: /v1 beispielsweise als Basispfad.
Basispfade müssen mit „/“ beginnen. API Gateway lehnt URLs ab, die kein Schema haben oder mit „/“ beginnen, um einen Basispfad anzugeben.
Nicht unterstützte Erweiterungen
API Gateway unterstützt die Erweiterung x-google-allow für OpenAPI 3.x nicht.
Maximale Dateigrößen
API Gateway erzwingt eine maximale Gesamtgröße von 10 MB und eine maximale Anzahl von 50 Dateien für hochgeladene OpenAPI 3.x-Dateien.
Einschränkungen von MCP
Während der öffentlichen Vorschau gelten die folgenden Einschränkungen für die Unterstützung des Model Context Protocol (MCP):
- Beschränkung der Anzahl der Tools: Kunden können pro Gateway maximal 1.000 MCP-Tools verwenden.
- HTTP-Methoden: Nur Vorgänge vom Typ
GET,POST,PUT,PATCHundDELETEkönnen als MCP-Tools bereitgestellt werden.HEAD,OPTIONSundTRACEwerden nicht unterstützt. - Streaming: Das SSE-Streaming (Server-Sent Events) von Tool-Aufrufen mit langer Ausführungszeit wird nicht unterstützt.
- Batchanfragen: JSON-RPC-Batcharrays werden abgelehnt.
- Multimodale Nutzlasten: Tool-Antworten sind auf UTF-8-Text beschränkt. Binäre Antworten werden nicht unterstützt.
- Zustandslosigkeit: Die Implementierung ist zustandslos. Sitzungskennungen (wie
MCP-Session-Id) werden nicht verwendet oder verwaltet. - Nicht unterstützte MCP-Methoden: Spezialisierte Methoden wie
resources/*,prompts/*,sampling/*,completion/*,pingundlogging/*werden nicht unterstützt und geben den JSON-RPC-Fehlercode-32601zurück. - Keine Tool-Anmerkungen: Hinweise wie
destructiveHintoderreadOnlyHintwerden in Tool-Deklarationen nicht ausgegeben. - CORS-Preflight: Die automatische Verarbeitung von CORS-Preflights (
OPTIONS-Anfragen) für den Pfad/mcpwird nicht vom Gateway verwaltet. - Gegenseitiger Ausschluss von Modellrouting: Sie können MCP und Modellrouting nicht in derselben API-Konfiguration verwenden.
- Nicht unterstützte MCP-Antworten: Vorgänge, bei denen in der Antwort leere Texte zurückgegeben werden, z. B. HTTP 204-Antworten, werden nicht unterstützt.
- Schemaermittlung: Komplexe, verschachtelte Objektschemas, die aus Ihrer OpenAPI-Spezifikation abgeleitet werden, werden aufgrund einer bekannten Einschränkung bei der Konfigurationsverarbeitung möglicherweise nicht vollständig oder korrekt in der
tools/list-Ermittlungsantwort gerendert.
Bestehende Einschränkungen
In diesem Abschnitt werden Einschränkungen aus OpenAPI 2.0 beschrieben, die auch für OpenAPI 3.x gelten.
Ignorierte Bereiche
API Gateway akzeptiert zwar OpenAPI-Dokumente mit Bereichen, die in einem Sicherheitsschemaobjekt definiert sind, prüft oder erzwingt diese Bereiche jedoch nicht.
Mehrere Sicherheitsanforderungen
- Anforderungen an API-Schlüssel: API Gateway unterstützt keine alternativen (logischen ODER) Sicherheitsanforderungen, wenn eines der Schemas ein API-Schlüssel ist. API Gateway unterstützt jedoch Konjunktionen (logisches UND), sodass Sie sowohl einen API-Schlüssel als auch ein OAuth2-Token anfordern können.
- OAuth2-Anforderungen: API Gateway unterstützt alternative (logische ODER) Sicherheitsanforderungen für verschiedene OAuth2-Sicherheitsschemas. API Gateway unterstützt keine Konjunktionen (logisches UND), es sei denn, die zusätzliche Sicherheitsanforderung ist ein API-Schlüssel.
- Optionale Sicherheit: Sie können eine leere Sicherheitsanforderung (
- {}) verwenden, um die Sicherheit für einen API-Schlüssel optional zu machen. API Gateway unterstützt dies jedoch nicht für OAuth.
Validierung der Sicherheitsdefinition
API Gateway lehnt eine OpenAPI 3.x-Spezifikation ab, in der eine Sicherheitsanforderung ohne entsprechende Definition im Abschnitt securityDefinitions verwendet wird.
URL-Pfadvorlagen
API Gateway unterstützt nur URL-Pfadvorlagenparameter, die ganze Pfadsegmente darstellen, z. B. /items/{itemId}. API Gateway unterstützt keine Parameter, die sich auf Teilsegmente beziehen, und lehnt sie ab, z. B. /items/prefix_{id}_suffix.
Parameter, Schemas, Anfragetexte und Typen
API Gateway akzeptiert OpenAPI-Dokumente mit verschiedenen Parameter- und Typdefinitionen (z. B. required-Parameter und Array-Formate), erzwingt sie aber nicht. API Gateway leitet eingehende Anfragen unabhängig von diesen Definitionen an Ihre API weiter.
API Gateway unterstützt nur primitive Typen in Anfrageparametern.
Verweise auf externe Typen
API Gateway unterstützt keine Verweise auf Typen außerhalb des bereitgestellten OpenAPI-Dokuments. API Gateway lässt beispielsweise keine $ref zu, die auf eine externe URL verweist, und lehnt sie ab.
Benutzerdefinierter Port in der Hostadresse
API Gateway lässt keine benutzerdefinierten Ports im Feld servers.url eines OpenAPI-Dokuments zu.
Einschränkungen für YAML-Aliasse
Ein an API Gateway gesendetes OpenAPI-Dokument kann maximal 200 YAML-Alias-Knoten enthalten.