如果你现在的做法是把一个 HTTP 连接挂住 20–50 秒,就该换成这套接口。已经跑通的同步集成
不必急着迁移,先看怎么在同步和异步之间选。
端点
注意创建用复数
tasks,查询用单数 task。没有列表、取消、删除端点。
创建任务
请求体永远是这三个键的信封:model、input,以及可选的 callback_url。
信封字段
信封层的未知字段目前会被接受并忽略。不要依赖这个行为,更不要把生成参数写在这一层——
它们属于
input。
input 对象
input 装的是生成参数,而它接受哪些字段取决于模型。外层信封是固定的,
里面装什么不是。
input 内部的校验很严:模型不认识的键会被直接拒掉,所以拼错字段名会立刻报错,
不会被静默忽略:
Nano Banana 系列
完整字段清单、分辨率档位、画幅比例与图生图用法。
轮询结果
任务字段
响应是随任务推进逐步长出来的——任务还在跑的时候,
outputs 和 expires_at 根本不存在。
读字段时别假设固定结构,先按 status 分支。
状态流转
该等多久
提交是亚秒级的,压力下也稳:30 个任务、并发 12 实测 p50 0.88 秒、p95 0.92 秒。 时间都花在生成上——按模型和分辨率不同,大约 12–50 秒,其中 0–11 秒是排队。 分模型的具体数字在各自的模型页上。下载产物
outputs 里是普通 https URL,没有签名也没有查询串,由 WideRouter 的分发 CDN
提供——域名和 API 不是同一个。由此有两件事要注意:
1
它们不鉴权
不要把 API Key 发给这些地址,同时把 URL 本身当成密钥看待:拿到链接的人在有效期内
都能取到图。
2
24 小时后失效
expires_at 恒为 created_at 加 86400。需要长期保留的内容要转存到你自己的存储,
不要把产物 URL 当成永久引用存下来。1K 约 0.4–0.7 MB,2K 约 2.4–3.0 MB,
4K 约 7.5–8.2 MB。文件类型请从响应的 Content-Type 读,不要靠扩展名猜。
回调
创建时带上callback_url,WideRouter 会在任务结束后把任务对象 POST 过去,
你就不用轮询了。
https。http、光秃秃的主机名、非字符串,都会在提交时就被
invalid_callback_url 拒掉,写错了当场报错,而不是投递不到也没人知道。
WideRouter 以 application/json 投递任务对象,并带上可以在解析正文之前先用来分流的头:
正文与同一时刻
GET /v1/task/{task_id} 的返回逐字节相同——字段一样、值一样——
所以一个 handler 可以同时服务两条路径。
实测投递很快:三个任务的回调都在任务进入 completed 后一秒内到达。如果你的接收端
返回 5xx,WideRouter 会重试,观测到的三次投递分别在约 0、10、70 秒。
回调是省掉延迟的优化,不是投递保证。要给收不到回调的任务留一条轮询兜底,
并且让 handler 幂等——按任务
id 去重,因为重试意味着同一个任务可能到达多次。任务失败时
failed 的任务在查询端点上依然是 200。失败信息在正文里,不在 HTTP 状态码上:
outputs,也没有 expires_at。取输入图失败会很快——不到一秒——
因为它发生在任何模型计算之前。
提交时的错误
校验发生在入队之前,所以这里的400 不产生任何费用。
错误一次只指一个字段,
param 用的是包含数组下标的完整路径(input.images[0]),
可以直接映射回你的请求。
哪些模型能走这条链路
模型 ID 精确匹配,没有别名互通,带-preview 后缀的名字也不接受。
传一个异步接口不服务的 ID,会在提交时就返回 model_not_supported,不会入队。
Nano Banana 系列
Google 的图像模型——两条链路各自的可用性、参数,以及实测时延。
怎么在同步和异步之间选
两套接口并存,都没有被废弃。
跑在 Serverless 函数、反向代理或移动端后面的场景应当默认用异步——这几类环境都不能
可靠地扛住一个 50 秒的请求。只想拿到图片字节的脚本,同步调用仍然更简单。
下一步
Nano Banana 系列
参数对照矩阵、分辨率档位,以及两个模型的差异。
快速开始
同一套流程,五分钟跑通。