在動態整合中，尤其是在自動化工作流程 (例如 Chains) 中使用 HTTP 連接器時，有效處理 API 呼叫的回應至關重要。輸出參數允許使用者擷取 API 傳回的重要資料，例如回應正文、回應標頭和狀態代碼，以便在下游步驟中使用這些資料。
這能解決什麼問題？
輸出參數對於建立反應迅速的智慧型工作流程至關重要。
- 動態工作流程： 輸出參數可根據 API 回傳的內容，量身訂做下一步的動作 - 例如，擷取標記、檢查記錄是否存在，或確認成功的作業。
- 自動化： 透過自動擷取值，使用者可避免手動輸入或硬式編碼，讓工作流程以更少的維護來擴充。
- 簡化整合： 由於連接器可根據接收到的資料進行調整，因此可更順暢地連接認證伺服器、CRM 或自訂 API 等系統。
這會對誰造成影響？
- 開發人員和整合人員： 建立自動化鏈或系統之間的整合。
- 資料分析師： 依賴即時、精確資料流來執行儀表板或報告的人。
- 系統管理員： 維護整合並排除故障的人員 - 能存取輸出參數有助於快速找出問題。
什麼是輸出參數？
HTTP Connector 中的 Output Parameters 用於定義 HTTP 請求的預期輸出，例如回應標頭、回應正文或回應碼。這些定義了 HTTP 請求的預期結果，這些結果可以重複使用在後續節點或鏈中的邏輯步驟。
輸出參數範例：
- 回應標頭： 元資料，例如內容類型、伺服器或速率限制狀態。
- 回應正文： API 傳回的實際內容 - 通常為 JSON 或 XML 格式。
- 回應代碼： 表示成功 (200)、客戶端錯誤 (400)、伺服器錯誤 (500) 等。
範例：擷取存取權限
假設 API 會傳回這樣的標記：
{ "token_type": "Bearer", "expires_in": 600, "access_token": "<access_token_string>", "scope": "graph:write graph_api|r permissions|w ..." }您可以將access_token 定義為輸出參數，然後將它傳給下一個步驟 (例如，驗證另一個 API 呼叫)。
為什麼需要回應正文？
回應正文 (Response Body) 通常是 API 傳回最重要資訊的地方。這些可能包括，但不限於：
- 新建立記錄的 ID
- 驗證令牌
- 查詢結果或資料有效負載
如果無法存取回應正文，就只能存取元資料，這會限制工作流程的動態性。
現在我們可以在回應下拉選項中取得access_token 。
常見的錯誤處理情況
使用輸出參數時可能遇到的典型問題：
-
錯誤： 未定義的輸出參數
原因與修復方法： 回應正文結構已變更或已巢狀。確認欄位的 JSON 路徑正確。
-
錯誤： 401 未經授權
起因與修復方法： Token 遺失或過期。確保擷取並正確傳送令牌。
-
錯誤： 500 伺服器內部錯誤
原因與修復方法： 伺服器問題或無效的要求有效載荷。檢查回應正文以瞭解更多內容。
-
錯誤： 無效 JSON
起因與修復方法： API 傳回畸形回應。使用 Try-Catch 區塊或在解析之前驗證輸出。
什麼是不記名權杖，為什麼需要它？
承載令牌是 OAuth 2.0 身份驗證中使用的一種存取令牌。它授權使用者或應用程式存取 API。之所以稱為「承載」，是因為您在 HTTP 請求的標頭中「承載」了記號。
範例標頭：
授權：Bearer<access_token>
這個權杖比基本認證更安全，因為：
- 它會過期，降低代幣洩漏的風險。
- 它可以攜帶範圍和權限。
- 它將認證與授權分開。
為什麼不直接使用基本驗證？
雖然 Basic Auth 會在每個要求中傳送編碼的使用者名稱和密碼，但它：
- 安全性較低 - 可重複使用或截取憑證。
- 無法輕易過期或設定存取範圍。
- 缺乏基於令牌的權限控制。
承載式權杖支援權杖過期、更新和細粒權限，因此是現代 API 和企業級安全性的最佳選擇。