如果你現在的做法是把一個 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 系列
參數對照矩陣、解析度檔位,以及兩個模型的差異。
快速開始
同一套流程,五分鐘跑通。