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的模范园林中流出响应，在生成时流出后端，在其它任何地方你主机都以同样的方式工作。 除了Apigee和Agent Gateway在Gemini平台之外，API Gateway是Google云的AI网关能力的轻量级入口。
API Gateway 现在支持全系列流化模式现代API依赖：
- Server-Sent Events(SSE)——向浏览器或客户端SDK传输流模式输出的事实上的标准，以及大多数OpenAI兼容聊天完成API背后的传输。
- 中断转移编码和HTTP反应流——包括新线限定JSON(NDJSON)和任何其他逐渐交付的反应机体。 反应通过后端产生，而不是缓冲，最后交付。
- WebSockets——用于聊天、协作、现场仪表板、通知和互动会话的全复式连接。
- gRPC流化——服务器侧流化和双向流化，因此可以在之前无法代理的gRPC服务前放置一个网关。
溪流最多可开放1小时。 和任何长寿的连接一样，客户端应该执行重联逻辑，这样一个会话在流的末端存活下来——一个行为良好的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-07-29). Gateway ID-PROJECT Number.region.gateway.dev.
(例：流经-测试-12345.us-central1.gateway.dev).
先前的默认网关。 dev 主机名包含一个生成的散列，这意味着要等到创建后才能知道网关的URL. 这是一个引起许多摩擦的小问题：你不能将端点写成客户端配置，一个Terraform模块，一个CI管道，一个防火墙许可列表，或者一个伙伴集成文件，直到资源存在为止——如果你把环境拆下来重建，那么你下面的URL就会改变。
现在主机名是您已经选择的值的纯函数。 您可以生成，模板化，文档化，并在网关存在前承诺源控，每次在同一工程和地区重建同一个网关时都会得到相同的URL. 对于任何以代码管理环境，或促进配置从dev到中继到prod，这可以消除整个类型的拖带问题。
流化并不是AI应用的特色——这是预期的互动模式。
用户期望看到一个模型的反应在生成时出现，而不是在三十二暂停后出现。 Agents需要报告中间步骤。 工具调用协议和远程MCP服务器依赖于长寿命，递增交付的连接。 一个无法流出的API管理层严重限制了AI应用程序的用户体验。
随着流畅，API Gateway成为了这种代理交通的可行前门——一个前门的价值与往常完全相同，只是更为紧迫。 AI端点价格昂贵，消耗配额，需要每个消费者认证和限制费率，需要观察。 这些是AI网关打算解决的治理问题。 另一种选择——每个团队在自己的模式终点前站起自己的代理人——是各组织最终如何无法回答关于谁在称呼什么的基本问题。
API Gateway中的模型路由让您在请求有效载荷中基于模型场向Gemini,Claude，或OpenAI,gpt-oss的模型显示一个单一的OpenAI兼容端点和发送请求。 模式路由+流线是指客户端获得一个熟悉的，基于标准的流线接口，而您则保留对哪些模式可以到达的集中控制，由谁到达，在什么政策下达到。
流线，模型路由和MCP支持都是API Gateway内部的功能，为Google Cloud内部的AI网关能力提供轻量级的 on-ramp. 这些AI网关能力允许团队在他们的生态系统中监控，安全和控制工具，模型和agents的代理流量，它们作为可堆肥的套件交付，这样你就可以为每个使用案例选择正确的网关。 对于范围更广的AI政策和完整的生命周期管理，使用Apigee. 为了管理和保障agent的连通性，在Gemini平台使用Agent Gateway. 您也可以结合这些网关：API Gateway 或 Apigee 可以坐在您的 agents 和 API 前面，或 Agent Gateway 后面，这样您的 agents 就可以到达模型，工具，和 MCP 服务器。 例如，您可以通过agent的Egress通过Agent Gateway进行严格的安全治理，然后将请求传递到API Gateway处理模型路由。
功能在预览中时需要规划的几件事：
- 在网关创建时间启用流线。 现有的网关不能就位转换；用旗子创建新的网关来尝试。
- 初始预览版发布不提供一些API Gateway功能，但将在预览期内出现。
- 通过无服务器的 NEG 和一个外部应用程序负载平衡器自定义域
- 通过云台流水
- 轨道
- 延迟衡量尺度反映流期。 对流线连接的请求延迟度测量流线的寿命，而不是时间到第一字节，所以期望长寿命的连接会改变您流线图的形状。
如果你已经使用 API 网关，看到这个工作最快的方法是将一个新的流源启用的网关指向现有的后端，释放 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 Atlas. All rights belong to the original author.