HTTP 請求節點

定義：

HTTP 請求節點是一個功能元件，設計用來與外部伺服器或 API 進行通訊。它能夠透過發送標準 HTTP 請求來交換和操作外部資料及效能數據，非常適合用於檢索外部資料、建立 Webhooks、生成圖像及下載檔案等情境。

快速開始/如何使用：

節點配置詳情：在 GoInsight.AI 中，右鍵點擊並選擇「Add Node」即可將 HTTP 請求節點新增至工作流程。

1. 配置 HTTP 請求的 API 參數

API：HTTP 節點的 API 模組提供了一個方便的介面，可用於 API 呼叫。使用者只需輸入目標 API 位址，即可從六種標準 HTTP 方法中選擇合適的請求方式：

GET：用於請求伺服器發送特定資源。

POST：用於提交資料至伺服器，通常用於提交表單或上傳檔案。

HEAD：類似於 GET 請求，但伺服器不傳回請求資源的主體，只傳回回應標頭。

PATCH：用於獲取請求-回應鏈中每個節點的傳輸路徑。

PUT：用於上傳資源至伺服器，通常用於更新現有資源或建立新資源。

DELETE：用於請求伺服器刪除指定的資源。

例如，要訪問 AirDroid 官方網站，請求方法通常是 GET：https://www.airdroid.com。

HTTP 節點允許您在 URL 輸入框中插入變數，方法是輸入「/」或「{」。變數的來源可以是上游節點的輸出、使用者輸入或系統變數。

例如，使用系統變數 Query（在對話式工作流程中），輸入「/」或「{」後，選擇 Query 即可將使用者輸入的問題作為此請求節點的目標位址。

1) 「Run This Step」是一個節點偵錯功能，允許開發者獨立執行與驗證工作流程中的特定節點。點擊介面右上角的「Run This Step」按鈕後，僅當前選定的節點會被執行，以便精確定位問題。

2) 「Follow This Node」也是一個節點偵錯功能。啟用此功能後，系統會自動將此節點中使用的所有變數標記為監看變數，並在偵錯面板中即時顯示其摘要資訊，幫助您快速掌握工作流程的狀態。

2. 配置 HTTP 請求標頭和參數

1) Headers 是附加在請求或回應上的後設資料。它們提供有關請求的額外資訊，類似於信封上的郵票和位址提供有關信件的額外細節。

功能：包含有關請求的補充資訊，例如請求類型、發送者資訊、資料格式等。

• Content-Type：指定發送數據的格式（例如 application/json, application/x-www-form-urlencoded 等）。
• Authorization：包含 API 的身份驗證資訊，例如權杖。
• 其他自定義請求標頭也可以使用。

2) Params 是附加到 URL 的鍵值對，用於傳遞額外的查詢資訊。這就像告訴餐廳服務生您想要額外的鹽或選擇不同的配菜。

功能：用於過濾或指定請求的某些條件。

如果有多組標頭/參數，可以點擊右上角的 "+" 來添加更多，點擊右下角的 "delete" 來移除它們。

3. 配置 HTTP 請求的主體內容

主體是請求中傳輸的實際數據內容。它就像信件的主要文本，包含您想要傳達的主要資訊。

功能：包含需要發送至伺服器的資料，例如表單資訊、檔案內容等。

主體格式：HTTP 節點提供靈活的請求主體格式配置，支持五種常見數據格式，以滿足不同接口要求：

1. None：表示發送請求時不附加資料。這種情況常見於以下情境：

• GET 請求：GET 請求通常用於從伺服器檢索資料，而非發送資料，因此通常不需要請求主體。在此情境下，「主體」通常為「None」。
• DELETE 請求：類似於 GET 請求，DELETE 請求通常用於刪除資源，因此不需要請求主體。
• 不需要資料：某些 API，如簡單的觸發操作或狀態查詢，設計上不需要請求主體。
• 預設設定：如果請求類型支援請求主體（如 POST 或 PUT），但在特定情境下不需要任何資料，則主體也可以設為 None。

2. form-data：發送表單資料的格式，通常用於檔案上傳。

• 使用：主要用於需要檔案上傳的情境，因為它可以處理二進位和文字資料。
• 實現：使用「
  multipart/form-data
  」作為「
  Content-Type
  」，每個欄位有自己的內容描述和邊界。
• 不需要資料：某些 API，如簡單的觸發操作或狀態查詢，設計上不需要請求主體。
• 範例：用於在 HTML 表單中選擇檔案上傳。

3. x-www-form-urlencoded：以鍵值對形式編碼表單資料，發送 URL 編碼格式的資料。

• 使用：適合發送簡單表單數據，通常用於 POST 請求。
• 實現：資料以「
  key1=value1&key2=value2
  」格式發送至請求主體中，特殊字元會被編碼。
• 範例：提交 HTML 表單時預設使用此格式。

4. raw text：指發送未經特定編碼格式的純文字資料。

• 使用：適合需要發送純文字資料的情境。
• 實現：可以指定「
  Content-Type
  」為「
  text/plain
  」來直接發送未編碼的文字。
• 範例：發送簡單的文字訊息或日誌資料。

5. JSON：用於發送結構化的 JSON 資料。

• 使用：廣泛用於「
  RESTful APIs
  」，因為 JSON 易於閱讀和解析。
• 實現：使用「
  application/json
  」作為「
  Content-Type
  」，資料以 JSON 格式發送。
• 範例：發送複雜的物件或陣列資料，例如「{"name": "John", "age": 30}」。

4. HTTP 請求超時設定

超時設定是一個閾值參數，用於控制請求等待回應的最大時間。您可以根據需要設定超時持續時間（以秒為單位），預設值為 30 秒。

功能：它有助於防止工作流程卡住或延遲；它會強制終止那些無限期等待但沒有回應的請求。

常見的 HTTP 回應狀態碼

在 HTTP 請求過程中，伺服器會傳回不同的狀態碼，以指示請求的成功、失敗或需要進一步的操作。以下是常見的 HTTP 狀態碼分類及其處理方法，可根據需要進行處理：

典型使用案例：

HTTP 請求節點像是一座橋樑，促進您的系統與其他外部服務或應用程式之間的通訊。想像您的工作流程需要從外部來源獲取資訊或發送資訊出去，這時 HTTP 請求節點就派上用場了。

• GET 請求：GET 請求通常用於從伺服器檢索資料，而非發送資料，因此通常不需要請求主體。在此情境下，「
  主體
  」通常為「
  None
  」。
• 呼叫第三方 API 以收集資料：例如，透過連結檢索 YouTube 影片的標題、訂閱者數量和觀看次數。
• 與內部企業系統整合：例如，使用企業系統的 API 介面定期發送收集的資訊。

實際案例情境：

客戶支援系統中自動化票務分類工作流程的設計步驟：

• 1. 開始節點：
  • 收集客戶提交的資訊，包括帳號詳情、問題描述、優先級和問題類型。
• 2. HTTP 請求節點（建立票務）：
  • 請求方法：POST
  • URL：票務建立的 API 端點。
  • 主體：包含客戶資訊、問題詳情、優先級和問題類型。
  • 輸出：檢索已建立的票務 ID。
• 3. 自然語意分類器（問題分類）：
  • 分類使用者提出的詢問，例如技術問題和計費問題。
• 4. HTTP 請求節點（分類至技術支援部門）：
  • 請求方法：POST
  • URL：技術支援團隊內部系統的 API 端點。
  • 主體：包含票務ID和問題詳情。
• 5. HTTP 請求節點（分類至計費支援部門）：
  • 請求方法：POST
  • URL：計費支援團隊內部系統的 API 端點。
  • 主體：包含票務ID和問題詳情。
• 6. 結束節點：完成工作流程。

透過此工作流程，票務可以在客戶填寫必要資訊後自動建立，然後自動分類。

注意事項

• 法律風險：遵守機器人排除協定，以避免非法網頁抓取。
• 速率限制：第三方 API 通常有 QPS（每秒查詢數量）限制，以確保所有使用者都能公平存取。
• 成本控制：某些 API 會根據呼叫次數收費；請注意定價。

常見問題解答

Q1: 如何處理超時問題？

調整超時設定參數，預設值為30秒，可根據需要進行修改。

Q2: 如何找到合適的API？

許多網站提供各種API接口，例如rapidapi.com。