OCT. 22, 2026 (英语).
在过去十年的大部分时间里，一个API的电话看起来像一个交易。 一个客户端发出一个请求，等待，并得到了完整的答复完整地回复。 这个模型正是大多数API管理工具——包括API Gateway——用来处理的，它仍然描述了大量的生产流量。
但这不再描述所有的交通类型。 生成反应的模型在生成时会发出信号，而不是在结尾分批发出。 agent通过多步骤任务工作，报告进展。 一个仪表板，一个合作编辑器，一个活的推论端点——这些都需要一个保持开口并同时带入双向数据的连接。
直到现在，在API Gateway上构建这些体验的开发者不得不做出一个令人不适的选择：将API Gateway置于他们的API前并放弃流线，或路由流端绕出网关，并放弃认证，API密钥执行和可观察性，使得网关在最初成为必要的。 团队最终拥有了分立的地产——管理一条道上的API，另一条道上的通流交通不受管理。
我们宣布 API Gateway中的流媒体支持在公共预览中提供。 与你所服务的其他一切一样，你的源源不断的终点可以坐落在同一个网关后面，有同样的政策。
对于AI应用程序，流化还加强了API Gateway与Gemini平台的连接。 在Gemini平台的模范园林中，一个使用模式路由的网关现在来自Gemini,Claude和OpenAIZ-3Z-oss模型的流回响应，当其生成时，流回后端在其它任何地方都以同样的方式工作。 除了Apigee和Agent Gateway在Gemini平台之外，API Gateway是Google Cloud的AI网关能力的轻量级入口。
API Gateway 现在支持全程流化模式现代API 依赖：
- Server-Sent Eventions (SSE)——向浏览器或客户端SDK提供流出模型输出的事实上的标准，以及大多数OpenAI相容的聊天完成API背后的传输。
- 被中断的转移编码和HTTP响应流——包括新线受限JSON(NDJSON)和任何其他逐渐交付的响应体。 由于你的后端产生反应，而不是缓冲，并在最后发出。
- WebSockets——用于聊天、协作、现场仪表板、通知和互动会话的全复式连接。
- gRPC流出——服务器侧流出和双向流出，可以将一个网关放入之前无法代理的gRPC服务前。
溪流最多可保持一个小时开放。 与任何长生连接一样，客户端应该执行重联逻辑，这样一个会话在流的末端存活下来——一个行为良好的WebSocket或SSE客户端无论如何都应该这样做。
这是我们最满意的部分：没有新的东西可以学习。
流化不是不同的产品，不同的资源类型，也不是描述您 API 的不同方式。 没有新的扩展可以添加，没有流化特定的说明，没有单独的流化操作的光谱。 描述您已有的 API 的文档。
所有你已经依赖的东西继续工作完全如前：
- API关键执行
- JWT验证，包括Firebase、Auth0、Okta和Google标识符
- 服务账户认证到后端
- 云记录和云监测一体化
- 路径诱导和请求路径
在公共预览期间，您在创建网关时选择进入：
gcloud api-gateway 网关创建 GATEWAY ID \
--api=API_ID \
--api-config=CONFIG_ID \
地点=区域
--可流化
纯文本
复制
这面旗帜是完全不同的。 在 GA 中，计划流线将仅仅是 API Gateway 如何表现，不需要选择进入，如同预览期间，您的 API 配置没有更改。
在流出的同时，网关获得一个决定性的默认主机名：
(原始内容存档于2017-10-12). Gateway ID-PROJECT Number.region.gateway.dev.
(例：流出-测试-12345.us-central1.gateway.dev).
先前的默认网关。 dev 主机名包含一个生成的散列，这意味着在您创建后才能知道您的网关的 URL。 造成许多摩擦的小事：你不能把端点写入客户端配置，一个Terraform模块，一个CI管道，一个防火墙许可列表，或者一个合作伙伴集成文件，直到资源存在为止——如果你把环境拆了重建，那么你的下方的URL就会改变。
现在主机名是您已经选择的值的纯函数。 您可以在网关存在之前生成，模板化，文档化，并致力于源控，每次在同一个工程和地区重建同一个网关时都会得到相同的URL. 对于任何以代码管理环境的人，或推动一个配置从dev到中继到prod，这可以消除整个类型的拖带问题。
流出并不是AI应用的特有功能——这是预期的互动模式。
用户期望看到一个模型的反应在生成时出现，而不是经过一32个暂停后出现。 Agents需要报告中间步骤。 工具调用协议和远程MCP服务器依赖于长寿命，递增交付的连接。 API管理层无法流出严重限制了AI应用程序的用户体验。
随着流出，API Gateway成为了这种代理交通的可行前门——而前门的价值与往常完全一样，只是更为紧迫。 AI端点昂贵，消耗了配额，需要每个消费者的认证和利率限制，并且需要可观察。 这些是AI网关打算解决的治理问题。 另一种方法是，每个团队在自己的示范终点站前站起自己的代理人，组织最终如何无法回答关于谁在称呼什么的基本问题。
API Gateway中的模型路由允许您根据请求有效载荷中的模型域向Gemini,Claude，或OpenAI,gpt-oss的模型显示一个单一的OpenAI兼容端点并发送请求。 模式路由+流化意味着客户端获得一个熟悉的，基于标准的流化界面，而您则保留对哪些模式可以到达，由谁，在什么政策下达到的集中控制。
流线，模型路由和MCP支持都是API Gateway内部的功能，为Google Cloud内部的AI网关能力提供轻量级的上-外延。 这些AI网关能力允许团队监测，安全并控制工具，模型和agents在生态系统中的代理流量，它们作为可堆肥的套件交付，这样您就可以为每个使用案例选择正确的网关。 对于范围更广的AI政策和全生命周期管理，使用Apigee. 为了管理和保障agent连接，使用Agent Gateway在Gemini平台。 您也可以结合这些网关：API Gateway或Apigee可以坐在您的agents和API前面，或Agent Gateway后面，这样您的agents就可以到达模型，工具，和MCP服务器。 例如，您可以通过 agent 的 Egress 通过 Agent 网关进行严格的安全治理，然后将请求传递到API网关处理模型路由。
功能在预览中时需要左右的几件事：
- 网关创建时间允许流出。 已存在的网关不能就地转换；用旗子创建出一个新的网关来尝试。
- 初始预览版发布不提供一些API Gateway功能，但将在预览版期间出现。
- 通过无服务器的 NEG 和外部应用程序负载平衡器自定义域
- 通过云台流出能力
- 轨道
- 延迟度量度反映流长。 请求流线连接的耐久性可以测量流线的生命，而不是时间到先字节，所以期望长生连接可以改变您流线图的形状。
如果你已经使用 API Gateway，最快的方法看到这个工作是在现有的后端指向一个新的流源启用的网关，发送 SSE 并监视事件逐渐到达。 不需要光谱变化。
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
OCT. 22, 2026
For most of the last decade, an API call looked like a transaction. A client sent a request, waited, and got a complete response back in one piece. That model is exactly what most API management tooling — including API Gateway — was built to handle, and it still describes a huge amount of production traffic.
But that no longer describes all traffic types. A model generating a response emits tokens as it produces them, not in one batch at the end. An agent working through a multi-step task reports progress as it goes. A dashboard, a collaborative editor, a live inference endpoint — these all need a connection that stays open and carries data in both directions.
Until now, developers building those experiences in API Gateway had to make an uncomfortable choice: put API Gateway in front of their APIs and give up streaming, or route streaming endpoints around the gateway and give up the authentication, API key enforcement, and observability that made the gateway essential in the first place. Teams ended up with a split estate — governed APIs on one path, ungoverned streaming traffic on another.
We're announcing that streaming support in API Gateway is available in Public Preview. Your streaming endpoints can now sit behind the same gateway, with the same policies, as everything else you serve.
For AI applications, streaming also strengthens API Gateway's connection to Gemini platform. A gateway that uses model routing now streams responses from Gemini, Claude and OpenAI gpt-oss models in model garden in Gemini platform as they're generated, and streaming backends you host anywhere else work the same way. Alongside Apigee and Agent Gateway in Gemini platform, API Gateway is the lightweight entry point to Google Cloud's AI gateway capabilities.
API Gateway now supports the full range of streaming patterns modern APIs rely on:
- Server-Sent Events (SSE) — the de facto standard for streaming model output to a browser or client SDK, and the transport behind most OpenAI-compatible chat completion APIs.
- Chunked transfer encoding and HTTP response streaming — including newline-delimited JSON (NDJSON) and any other progressively-delivered response body. Responses are passed through as your backend produces them rather than buffered and delivered at the end.
- WebSockets — full-duplex connections for chat, collaboration, live dashboards, notifications, and interactive sessions.
- gRPC streaming — server-side streaming and bidirectional streaming, so you can put a gateway in front of gRPC services that were previously impossible to proxy.
Streams can stay open for up to one hour. As with any long-lived connection, clients should implement reconnection logic so that a session survives the end of a stream — a well-behaved WebSocket or SSE client should be doing this anyway.
This is the part we are most pleased with: there is nothing new to learn.
Streaming is not a different product, a different resource type, or a different way of describing your API. There are no new extensions to add, no streaming-specific annotations, no separate spec for streaming operations. The same document that describes your existing API describes your streaming API.
Everything you already rely on continues to work exactly as before:
- API key enforcement
- JWT validation, including Firebase, Auth0, Okta, and Google ID tokens
- Service account authentication to backends
- Cloud Logging and Cloud Monitoring integration
- Path templating and request routing
During Public Preview, you opt-in when creating the gateway:
gcloud api-gateway gateways create GATEWAY_ID \
--api=API_ID \
--api-config=CONFIG_ID \
--location=REGION \
--enable-streaming
Plain text
Copied
That single flag is the entire difference. At GA, it is planned that streaming will simply be how API Gateway behaves, with no opt-in required and, as during Preview, no changes to your API config.
Alongside streaming, gateways get a deterministic default hostname:
GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev
(Example: streaming-test-12345.us-central1.gateway.dev)
Previously the default gateway.dev hostname included a generated hash, which meant you could not know your gateway's URL until after you had created it. That is a small thing that causes a lot of friction: you can't write the endpoint into a client config, a Terraform module, a CI pipeline, a firewall allowlist, or a partner integration doc until the resource exists — and if you tear the environment down and rebuild it, the URL changes underneath you.
Now the hostname is a pure function of values you already chose. You can generate it, template it, document it, and commit it to source control before the gateway exists, and you get the same URL every time you rebuild the same gateway in the same project and region. For anyone managing environments as code, or promoting a configuration from dev to staging to prod, this removes an entire category of bootstrapping problem.
Streaming isn't a niche feature for AI applications — it's the expected interaction pattern.
Users expect to see a model's response appear as it's generated, not after a thirty-second pause. Agents need to report intermediate steps. Tool-calling protocols and remote MCP servers depend on long-lived, incrementally-delivered connections. An API management layer that can't stream severely limits the user experience of AI applications.
With streaming, API Gateway becomes a viable front door for that agentic traffic — and the value of a front door is exactly the same as it's always been, only more urgent. AI endpoints are expensive, they consume quota, they need per-consumer authentication and rate limiting, and they need to be observable. These are the governance problems that an AI gateway is intended to solve. The alternative — every team standing up its own proxy in front of its own model endpoint — is how organizations end up unable to answer basic questions about who is calling what.
Model routing in API Gateway lets you expose a single OpenAI-compatible endpoint and dispatch requests to Gemini, Claude, or OpenAI gpt-oss models based on the model field in the request payload. Model routing plus streaming means clients get a familiar, standards-based streaming interface, while you retain centralized control over which models are reachable, by whom, and under what policy.
Streaming, model routing and MCP support are all features within API Gateway that provide a lightweight on-ramp to AI gateway capabilities within Google Cloud. These AI gateway capabilities allow teams to monitor, secure and control agentic traffic of tools, models and agents in their ecosystem, and they're delivered as a composable suite so you can choose the right gateway for each use case. For more expansive AI policies and full lifecycle management, use Apigee. To manage and secure agent connectivity, use Agent Gateway in Gemini platform. You can also combine these gateways: API Gateway or Apigee can sit in front of your agents and APIs, or behind Agent Gateway so your agents can reach models, tools, and MCP servers. For example, you can route your agent's egress through Agent Gateway for strict security governance, and then pass the request to API Gateway to handle model routing.
A few things to plan around while the feature is in Preview:
- Streaming is enabled at gateway creation time. Existing gateways can't be converted in place; create a new gateway with the flag to try it.
- A few API Gateway features are not available at the initial Preview launch, but will be coming during the Preview time period.
- Custom domains via Serverless NEGs and an external Application Load Balancer
- Streaming enablement via the Cloud console
- Terraform
- Latency metrics reflect stream duration. Request latency for a streaming connection measures the life of the stream, not time-to-first-byte, so expect long-lived connections to change the shape of your latency graphs.
If you're already using API Gateway, the fastest way to see this working is to point a new streaming-enabled gateway at an existing backend that emits SSE and watch the events arrive incrementally. No spec changes needed.
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.