使用 Logic 發起 HTTP 通信

開始之前： 查看 Logic 概述以熟悉 Logic。

利用 HTTP 請求是存取外部資源和增強網站互動性的有效機制。您有能力使用 Webflow Logic 建立 HTTP 通信 阻止尋求訊息 從 或傳達訊息 到 外部應用程式。隨後，您可以在工作流程中的以下步驟中使用回應資料 - 促進 Logic 與外部應用程式的無縫整合。 

在本教程中，您將掌握：

1. HTTP 請求由什麼組成？
2. HTTP請求的組成
3. 如何監督身份驗證憑證
4. HTTP 回應的組成
5. 如何測試 Initiate HTTP 通訊塊
6. 常見問題與問題解決

HTTP 請求由什麼組成？ 

HTTP，稱為超文本傳輸協議，是一種用於透過網際網路傳輸資料的協定。網際網路包括託管在眾多伺服器上的資源（例如，HTML 檔案、樣式表、腳本、圖片等）。 HTTP 請求可讓我們存取這些資源。

為了存取網路上的內容，您的瀏覽器（或「用戶端」）需要向這些伺服器發送請求以取得所需的資源。從伺服器接收到請求的資源後，瀏覽器將繼續向您展示這些資源。 HTTP 請求可讓您查看 這 目前頁面！ 

當您在瀏覽器的網址列中輸入「webflow.com」（或任何其他 URL）時，您的瀏覽器會向伺服器發送 GET 請求以檢索網頁，以便在瀏覽器中顯示該網頁。 得到 requests 表示客戶端可以存取的單一類型的 HTTP 方法來請求資源。我們將在本教學的稍後階段進一步深入研究其他流行的請求方法（POST、PUT、PATCH 和 DELETE）。 

利用 Logic 執行 HTTP 請求

在邏輯領域，您擁有自動向 API 發出 HTTP 請求的能力。 API（或應用程式介面）本質上充當中介，促進兩個不同應用程式之間的溝通- 在這種情況下，您的邏輯工作流程和外部技術框架（即用於增強您的網站功能的工具和服務的合併）。例如，您可以從 Airtable 請求記錄以合併到您的工作流程中，或將資料從 Webflow 網站傳送到 Airtable。 API 可讓您執行 CRUD 操作並為您的應用程式提供支援。 

CRUD 操作表示軟體應用程式應能夠執行的 4 種基本操作 — 建立、讀取、更新和刪除。使用者需要具備創建資料、讀取資料（即，獲得對應用程式使用者介面內的資料的存取）、更新或修改資料以及擦除資料的能力。您可以將 Webflow CMS 視為一個 CRUD 應用程序，您可以在其中建立、檢視（讀取）、修改（更新）和刪除 CMS 專案。 

流行的HTTP請求方式對應CRUD操作：

為了使用現實世界的比較來說明，API 類似於銀行，其中 CRUD 操作與銀行可行的活動並行。當您訪問銀行時，您可以訪問（讀）與您的可用資金和交易、存款（創造）錢存入您的帳戶， 更新 您的帳戶詳細信息，然後提款（刪除）從您的帳戶中取出資金。在銀行參與任何這些活動之前，您必須透過身分驗證自己的身分並向銀行說明您的意圖 - 類似的原則也適用於與 API 的互動。 

入門

要在 Logic 中啟動 HTTP 請求的過程： 

1. 使用權 邏輯面板 > 流量 > 流程編輯器
2. 拖曳一個 建立 HTTP 通信 塊到畫布上

HTTP請求的組成

HTTP 請求 應該 涵蓋：

• 一個請求方法
• 請求 URL 和端點路徑

此外，HTTP 請求可能包含：

• 驗證
• 請求體
• 請求標頭
• 查詢字串

驗證

類似於在銀行出示您的身份信息，許多 API 要求您在尋求資源時驗證並確定您的身份。存在 3 個身份驗證選項：

• 無（與不需要身份驗證的 API 相關）
• API令牌
• 使用者名稱密碼

評論： 所需的特定驗證憑證取決於您將要求導向的 API，因此您需要參閱相應的 API documentation 以取得此資訊。每個 API 的結構都不同，並非每種驗證格式都與所有 API 一致。 

深入了解有關管理身份驗證憑證的更多詳細資訊。

如何包含 API 令牌憑證

與密碼類似，API 令牌（有時稱為「API 金鑰」或「存取權杖」）用於表示對 API 產生 HTTP 請求的網站或應用程式。 Logic 中部署的所有 API 令牌均被安全地儲存。

基本的： 必須注意的是，儘管 Webflow 安全地儲存憑證，但 Webflow 無法控制透過邏輯工作流程接收該憑證的任何伺服器或第三方服務。 

評論： 您可以保留在請求標頭或查詢參數中合併 API 令牌的選項，具體取決於您將請求定向到的 API 的要求。 

在請求標頭內

開始之前： 請參閱 documentation，以了解用於接收您的請求的 API。這有助於確定如何以及在何處產生 API 令牌，以及如何建立請求標頭。標頭值所採用的名稱（例如，授權、X-API-Key 等）取決於接收請求的 API。進一步深入研究請求標頭。

若要在請求標頭中附加 API 令牌憑證： 

1. 複製你的 API令牌 指派給旨在接收您的請求的 API
2. 使用權 邏輯面板 > 流量 選項卡 > 流程編輯器 Webflow以內
3. 選擇 建立 HTTP 通信 畫布上的塊以揭開 區塊設定
4. 選擇 API令牌 之中確認 選擇器
5. 挑選 標題 來自 包括 選擇器
6. 在標題中插入一個值（例如，授權、X-API-Key 等） 標頭 盒子 
7. 按 選擇一個憑證 以下 鑑別
8. 按 新增標識 
9. 在中命名您的 API 金鑰（例如 Airtable API 金鑰） 標題 框中並提供摘要 定義 盒子如果你願意的話 
10. 選擇 API金鑰 來自 種類 選擇器
11. 貼你的 API金鑰 進入 驗證 盒子
12. 按 產生

基本的： 如果您傳送要求的 API 需要進行承載驗證，則您需要將「Bearer」包含在 代幣 API 金鑰之前的方格（例如 Bearer {token}）。

新增 API 金鑰後，您可以從 鑑別 未來 HTTP 請求的選擇器。

在查詢參數內

開始之前： 請參閱您發送請求的 API 的 documentation。這將有助於識別如何以及在何處產生 API 金鑰以及如何格式化查詢參數。用於查詢參數的鍵值對由您向其發送請求的 API 決定。了解有關查詢參數的更多資訊。

若要將 API 金鑰憑證合併到您的查詢參數中： 

1. 複製你的 API金鑰 對於您要向其發送請求的 API
2. 揭幕 合理化面板 > 洋流 選項卡 > 作品編輯 Webflow中
3. 選擇 API金鑰 來自 確認 選擇器
4. 選擇 查詢 來自 包括 選擇器
5. 將查詢參數的按鍵（例如，key=value 中的“key”，或 api_key=value 中的“api_key”）插入到 查詢參數 盒子
6. 按 選擇一個憑證 以下 鑑別
7. 按 新增標識 
8. 在中命名您的 API 金鑰（例如 TMDB API 金鑰） 標題 框並在其中添加摘要 定義 盒子如果你願意的話
9. 貼你的 API金鑰 進入 驗證 框 — 這將作為鍵值對中的值
10. 按 產生

基本的： 僅應將鍵值對中的鍵（例如 key=value 中的“key”）新增至 查詢參數 盒子。該值（即您的 API 金鑰）將自動附加到請求中的查詢參數。請記住，金鑰會根據您傳送要求的 API 的不同而有所不同，因此請參閱第三方的 API documentation 以了解此詳細資訊。 

新增 API 金鑰後，您可以從 鑑別 用於將來 HTTP 請求的選擇器。

如何合併使用者名稱和密碼識別

某些 API 可能需要使用使用者名稱和密碼而不是 API 金鑰進行驗證。 Logic 使用的所有使用者名稱和密碼均安全保存。 

基本的： 雖然 Webflow 安全地儲存驗證，但 Webflow 無法控制您使用邏輯流將該驗證傳輸到的任何伺服器或第三方服務。 

若要包含使用者名稱和密碼識別：  

1. 揭幕 合理化面板 > 洋流 選項卡 > 作品編輯 Webflow中
2. 選擇 發出 HTTP 請求 畫布上的塊以打開其 區塊設定
3. 選擇 使用者名稱密碼 來自 確認 選擇器
4. 按 選擇一個憑證 以下 鑑別
5. 按 新增標識
6. 在中命名您的識別（例如 Mailchimp 識別） 標題 框並在其中添加摘要 定義 盒子如果你願意的話
7. 選擇 使用者名稱密碼 在裡面 種類 選擇器
8. 在中輸入您的使用者名稱和密碼 使用者名稱 和 密碼 框（使用者名稱和密碼是來自外部服務的使用者名稱和密碼） 
9. 按 產生

輸入您的使用者名稱和密碼後，您可以從 鑑別 用於將來 HTTP 請求的選擇器。

請求 URL 和端點路徑 

每個 HTTP 請求必須包含請求 URL 和端點路徑，以指示您將請求導向的伺服器。 

例如，要使用 Mailchimp 建立新聯絡人 Mailchimp API，您將發出 POST 請求 https://{region}.api.mailchimp.com/3.0/lists/{listID}/members。在本例中，請求 URL 為 https://{region}.api.mailchimp.com/3.0 端點路徑是 /列表/{listID}/成員. 

您可以在中輸入請求 URL 和端點路徑 網址 的盒子 發出 HTTP 請求區塊設定。您也可以點選紫色“點URL 方塊中的「圖示將動態資料（例如，先前區塊的輸出資料）包含到您的請求 URL。 

筆記： 請求 URL 和端點路徑將根據您向其發送請求的 API 的不同而有所不同，因此您需要參考第三方的 API documentation 以了解此詳細資訊。

查詢字串

查詢字串是 URL 的可選元件，可讓您透過將資訊新增至 URL 末端來在伺服器之間轉送訊息。查詢字串通常位於 URL 中的問號 (?) 之後，並且可以包含一個或多個參數作為鍵值對。等號 (=) 分隔每個鍵和值（例如，key=value），與號 (&) 分隔多個參數（例如，key1=value1&key2=value2）。這些可以用於驗證（例如，將 API 金鑰新增至查詢參數）或轉發動態資料（例如，透過表單提交產生的資料）。 

假設您的目標是利用 電影資料庫 API 尋找有關電影 Hot Rod 的詳細資訊。您可以將 GET 請求發送至 https://api.themoviedb.org/3/search/movie?api_key={api_key}&query=Hot+Rod。在這種情況下， api_key和 搜尋 是關鍵字， {令牌} 代表真正的 API 令牌，並且 快+車 代表另一個值。這些關鍵字和值組成 2 個參數，共同形成查詢字串： ?token={token}&search=快速+汽車. 

透過點擊紫色“點” 中的圖標 網址 的領域 配置HTTP請求 區塊設定，您可以將動態資料（例如，先前區塊的結果資料）整合到查詢參數中。

筆記： 您在 HTTP 請求中包含的參數類型（如果有）及其結構將依賴您將請求轉送至的 API，因此建議諮詢外部 API documentation 以取得此見解。 

請求技術

HTTP 請求方法描述了請求的操作。後續的請求方法可以在 配置HTTP請求 堵塞： 

• 得到
• 郵政
• 放
• 修補
• 刪除

得到

人們可以利用 得到 請求技術來取得或讀取資源。一片繁盛 得到 請求產生包含所需資訊的回應主體。 

例如，一個 得到 request 擅長檢索 Mailchimp 中有關訂閱/受眾的數據，或 Airtable 資料庫中所有表格的列舉。 

郵政

這 郵政 請求技術對於在外部服務或資料庫中建立新資源非常有價值。 A 郵政 請求需要一個請求正文，您可以在其中定義要建構的資源的資料。 

假設您希望在 Webflow 網站上收集電子報訂閱者並將他們分派到 Mailchimp 清單。您可以建立一個包含表單提交觸發器和 配置HTTP請求 塊來傳達 郵政 向 Mailchimp 要求。此場景中的請求內文將封裝來自發送至 Mailchimp 的表單提交的資料。 

放

這 放 請求技術對於更改或更新資源很方便。如果沒有現有資源協調更新請求，則會出現新資源。許多第三方服務要求您在您的記錄中附上現有的記錄 ID 或獨特識別碼。 放 請求指示要修改的記錄，而不是他們的系統對現有記錄的存在執行判決。

基本的： 這 放 請求技術替代了 全部的 請求的資源以及請求正文中的資料。這意味著任何未指定的值都將覆蓋更新資源的當前值 - 在特定情況下存在潛在危險。用於更新一個 部分 現有資源的同時保留其餘資源不變，建議使用 PATCH 請求技術。

如果目標是更新 Airtable 中的現有記錄，則可以傳輸一條 放 向 Airtable 發出請求，同時附加 Airtable 中的整個記錄（即包含所有單元格值和當前記錄 ID 的完整佈局）以及請求正文中的預期修改。如果 Airtable 中尚不存在該記錄，則該請求將偽造一條新記錄。如果記錄已在 Airtable 中，且請求正文中任何現有儲存格值仍為空，則該請求將取代現有記錄 — 這表示先前填入的儲存格值將在請求執行後變為無效。 

修補

這 修補 請求技術反映了 放 然而，方法 修補 允許修改或更新 部分 資源的一部分，而不是整個資源。要更新的資料需要僅包含在請求正文中。

例如，如果調整 Airtable 中現有記錄的描述屬性而不更改其他屬性，則 修補 可以發送僅攜帶記錄 ID 和記錄的預期描述的請求。這 修補 request 僅調整記錄的指定字段，而其他屬性保持不變。 

刪除 

這 刪除 請求用於擦除資源。 

例如，人們可以發起一項 刪除 向 Mailchimp 要求拆除受眾，或向 Hubspot 要求從監控中刪除多餘的線索。

請求描述符

請求描述符產生有關 HTTP 請求的上下文，以便伺服器可以做出適當的回應。例如，在 GET 請求中，請求描述符可以指定所需的回應格式，或在 POST 請求中，它們可以指示正在轉送的資料類型。 

筆記： HTTP 請求中的請求描述符（如果有）根據您的請求指定的 API 的不同而有所不同，因此建議查閱外部 API documentation 以了解具體資訊。 

將請求標頭包含在 傳送 HTTP 請求 模組： 

1. 使用權 發送HTTP請求模組設置 > 一般的 > 標頭 
2. 點選“加“ 象徵 
3. 指定標頭的名稱和值

要刪除請求標頭，只需按一下“垃圾" 圖示.

提醒： 如果您在未輸入名稱和值的情況下建立標頭，流程編輯器會將其儲存為未知值。建議刪除未識別的標頭以防止問題。您可以透過點擊“垃圾” 圖示位於標題旁。

請求數據

請求資料包含您打算隨請求傳輸到伺服器的資訊。例如，在 POST 請求中，它可能是您希望產生的實體。對於某些請求來說，請求正文的存在不是強制性的 - 例如，當透過 GET 請求獲取資源時，不需要在正文中指定內容。這 請求數據 部分可見於 發送HTTP請求模組設置 > 一般的 當選擇需要請求正文的方法（例如，POST、PUT 或 PATCH）時。 

您將使用 JSON（JavaScript 物件表示法）建立請求正文。 JSON 是一種基於文字的資料格式，包含用雙引號括起來並用冒號分隔的鍵/值對，例如： 

“姓名”：“羅德金布爾”

形成請求正文的 JSON 物件可能包含多個鍵/值對，以逗號分隔。例如： 

{“姓名”：“羅德金布爾”，“職業”：“替身演員”}

至關重要的： 任何雜散的逗號、省略的冒號或缺少引號都可能導致 JSON 檔案無效，從而導致請求失敗。由於手動解析 JSON 的複雜性，使用像這樣的免費工具 JSONLint 建議進行驗證。 

您可以透過點擊紫色“將流中的動態資料整合到請求正文中”點” 中的圖標 正文 (JSON) 場地。支援的資料類型包括： 

• 清楚的
• 電子郵件
• 電話 
• 數位
• 文字區
• 檢查kbox
• 時間戳

筆記： 請求正文中包含的具體資訊將取決於您將請求分派到的 API；因此，諮詢第三方 API documentation 對於此資訊至關重要。 

管理身分驗證憑證

憑證（例如，API 令牌、使用者名稱、密碼等）安全地儲存在 Webflow 中 — 在傳輸期間和靜態時進行加密。一旦憑證建立，即使是其創建者也無法在 Webflow UI 中存取其實際值；僅指派給建立的憑證的使用者定義名稱可見。 

至關重要的： 雖然 Webflow 確保憑證的安全存儲，但它不管理透過邏輯流接收這些憑證的任何伺服器或第三方服務。 

新增憑證

若要引入新憑證，請導航至 區塊設定 > 驗證 > 選擇一個憑證 並選擇 新增憑證。包含憑證的過程會根據憑證類型（例如，API 令牌或使用者名稱和密碼）而有所不同。 

並得到伺服器的批准。以“2”開頭的代碼表示勝利回應。

200 好 是對蓬勃發展的 HTTP 請求的標準回复，但回复可能會根據請求方法而有所不同。 201 已建立例如，是對成功的最普遍的回复 郵政 要求。 

查看有關成功回應的 MDN documentation.

重定向回應

重定向狀態代碼表示客戶端需要採取額外的步驟來完成 HTTP 請求。如果請求有多個潛在回應或所請求資源的 URL 已永久更改，則可能會發生這種情況。以“3”開頭的程式碼表示重定向回應。 

探索重定向反應的 MDN documentation.

客戶端錯誤回應

客戶端錯誤狀態代碼表示由於客戶端觸發的問題，伺服器無法或不會處理請求。這意味著請求者（即您）方面有問題。可能會發出客戶端錯誤狀態代碼，以回應使用有缺陷的語法、缺乏必要的身份驗證、不存在的資源等發送的請求。 

請參閱有關客戶端錯誤回應的 MDN documentation.

伺服器錯誤回應

伺服器錯誤回應表示伺服器未能完成請求或無法完成請求。這顯示第三方服務方面存在問題。以“5”開頭的代碼表示伺服器錯誤回應。 

閱讀有關伺服器錯誤回應的 MDN documentation.

響應標頭

回應標頭是 HTTP 標頭，包含回應的額外上下文，例如有關回應伺服器、資料類型、主機位址等的詳細資訊。 

響應體

一旦 HTTP 請求成功，回應正文包括：

• 客戶端請求的資源，或 
• 有關客戶端請求的操作狀態的一些詳細信息

如果 HTTP 請求失敗，回應正文可能會提供：

• 進一步了解錯誤的原因，或 
• 客戶應採取的行動來完成他們的請求

並非所有回應都會包含回應正文。 

如何測試 Make HTTP 請求區塊

您可以獨立測試 發出 HTTP 請求 阻止您工作流程的其餘部分，以簡化故障排除。 

評估一個 發出 HTTP 請求 堵塞： 

1. 使用權 邏輯面板 > 流量 選項卡 > 流程編輯器 
2. 右鍵單擊 發出 HTTP 請求 畫布上的塊並選擇 測試這個動作，或選擇 發出 HTTP 請求 畫布上的區塊並單擊 運行測試 完成設定 在 區塊設定
3. 在模態選單視窗中輸入樣本數據
4. 按 運行測試

了解有關測試工作流程的更多資訊。

用於測試 HTTP 請求的其他資源

您可以利用免費服務，例如 webhook.site 或者 requestbin.com 測試 HTTP 請求。這些服務提供範例 API 端點，因此您可以驗證您的要求，而無需實際傳輸任何資料。 

您還可以利用 郵差，一個免費的 API 用戶端，用於深入研究 API 端點並測試 HTTP 請求。這可以幫助從 Logic 外部調試您的請求。 

常見問題與故障排除

我的 HTTP 請求未達到要求，但我不確定原因。 

您可以依靠回應狀態碼（有時還包括回應正文）來更深入地了解 HTTP 請求可能失敗的原因 - 例如，它可能會因客戶端錯誤或伺服器錯誤而失敗。 

如果您收到用戶端錯誤回應，則您的要求可能有缺陷。使用諸如以下的免費工具來驗證您的 JSON 可能會很有幫助 JSONLint 解決任何語法錯誤。 

也可以單獨測試一下 發出 HTTP 請求 塊以簡化故障排除。了解如何測試 Make HTTP 請求區塊。 

如果您仍然不確定 HTTP 請求失敗的原因，請聯絡您傳送要求的第三方服務以取得更多支援和資源。 

如果您認為 Make HTTP 請求區塊本身遇到問題，請 聯絡我們的客戶支援團隊尋求協助。請確保包含您的 流ID 與您的提交。 

PUT 和 PATCH 之間有什麼區別？ 

PUT 請求將會建構一個 新鮮的 資源（如果無法找到要更新的指定資源）。 PUT 請求技術也將整個請求的資源替換為請求正文中的資料。這意味著任何未指定的值都將覆蓋您更新的資源的現有值 - 這在某些情況下可能是有害的。 

透過 PATCH 請求，您可以修改 部分 透過僅呈現您希望更新的資料來存取資源。 

其他 Workspace 成員可以查看我包含的任何憑證（例如第三方 API 金鑰、使用者名稱和密碼）嗎？ 

工作區成員可以管理、使用和檢視憑證片段。儘管如此，一旦建立了憑證，任何人（包括該憑證的原始創建者）都無法在 Webflow UI 中查看該憑證的實際值。本質上，Workspace 成員可以觀察所建立憑證的使用者定義名稱，但無法存取 API 令牌或使用者名稱和密碼的實際值。

Webflow 如何儲存和管理憑證？ 

憑證被安全儲存－在傳輸過程中始終加密，並且在靜態時始終加密。一旦建立了憑證，任何人（包括該憑證的原始創建者）都無法在 Webflow UI 中查看該憑證的實際值。您只能查看所建立憑證的使用者定義名稱。 

請注意，雖然 Webflow 安全地儲存憑證，但 Webflow 不會管理您使用邏輯流將憑證傳輸到的任何伺服器。 

複製或轉移網站時，憑證會發生什麼情況？ 

複製或轉移網站時，不會保留憑證。複製或轉移網站後，您的流程中使用的任何憑證都需要重新建立。