ロジックを使用してHTTP通信を開始する

開始前に： Logic の概要を参照して、Logic について理解を深めてください。

HTTPリクエストを利用することは、外部リソースにアクセスし、ウェブサイトのインタラクティブ性を高めるための強力なメカニズムです。Webflowロジックの HTTP通信を作成する 情報を求めるブロック から または情報を伝達する に 外部アプリケーション。その後、ワークフロー内の次のステップで応答データを活用できるため、Logic と外部アプリケーションのシームレスな統合が容易になります。 

このチュートリアルでは、次のことを理解します。

1. HTTP リクエストを構成するものは何ですか?
2. HTTPリクエストの構成
3. 認証資格情報を監視する方法
4. HTTPレスポンスの構成
5. HTTP通信ブロックの開始をテストする方法
6. FAQと問題解決

HTTP リクエストを構成するものは何ですか? 

HTTP はハイパーテキスト転送プロトコルとも呼ばれ、インターネット上でデータを転送するために使用されるプロトコルです。インターネットは、多数のサーバーにホストされているリソース (HTML ファイル、スタイルシート、スクリプト、画像など) で構成されています。HTTP リクエストにより、これらのリソースにアクセスできます。

インターネット上のコンテンツにアクセスするには、ブラウザ（または「クライアント」）は、必要なリソースをサーバーに要求する必要があります。サーバーから要求されたリソースを受信すると、ブラウザはこれらのリソースを表示します。HTTPリクエストにより、 これ 現在ページです！ 

ブラウザのアドレスバーに「webflow.com」（またはその他の URL）を入力すると、ブラウザはサーバーに GET リクエストを送信し、Web ページを取得してブラウザ内に表示します。 得る リクエストは、クライアントがリソースを要求するためにアクセスできる単一のタイプの HTTP メソッドを表します。他の一般的なリクエスト メソッド (POST、PUT、PATCH、および DELETE) については、このチュートリアルの後半でさらに詳しく説明します。 

ロジックを利用したHTTPリクエストの実行

Logic の領域では、API への HTTP リクエストを自動化できます。API (アプリケーション プログラミング インターフェイス) は、基本的に、2 つの異なるアプリケーション (このシナリオでは、Logic ワークフローと外部テクノロジ フレームワーク (つまり、Web サイトを強化するために使用されるツールとサービスの統合)) 間の通信を容易にする仲介役として機能します。たとえば、ワークフローに組み込むために Airtable からレコードを要求したり、Webflow Web サイトから Airtable にデータを送信したりできます。API を使用すると、CRUD 操作を実行してアプリケーションを強化できます。 

CRUD 操作は、ソフトウェア アプリケーションが実行できる 4 つの基本的な操作 (作成、読み取り、更新、削除) を表します。ユーザーは、データの作成、データの読み取り (つまり、アプリケーション ユーザー インターフェイス内でデータにアクセスする)、データの更新または変更、およびデータの消去を行う必要があります。Webflow CMS は、CMS アイテムの作成、表示 (読み取り)、変更 (更新)、および消去を行うことができる CRUD アプリケーションとして考えることができます。 

一般的な 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 は資格情報を安全に保存しますが、Logic ワークフローを介してその資格情報を受け取るサーバーやサードパーティのサービスに対しては制御できないことに注意する必要があります。 

述べる： リクエストを送信する API の要件に応じて、リクエスト ヘッダーまたはクエリ パラメータ内に API トークンを組み込むオプションが保持されます。 

リクエストヘッダー内

開始前に： リクエストを受信する API については、documentation を参照してください。これは、API トークンを生成する方法と場所、およびリクエスト ヘッダーの構造を決定するのに役立ちます。ヘッダー値に使用される指定 (Authorization、X-API-Key など) は、リクエストを受信する API によって異なります。リクエスト ヘッダーについてさらに詳しく調べてください。

リクエスト ヘッダー内に API トークン資格情報を追加するには: 

1. コピーする APIトークン リクエストを受信するためのAPIに割り当てられます
2. アクセス ロジックパネル > 流れ タブ > フローエディタ Webflow以内
3. を選択 HTTP通信を作成する キャンバスにブロックを描いて明らかにする ブロック設定
4. 選ぶ APIトークン その中で検証 セレクタ
5. 選ぶ 見出し から 含める セレクタ
6. 見出しの値（例：Authorization、X-API-Keyなど）を ヘッダ 箱 
7. プレス 資格情報を選択 下に 識別
8. プレス 新しい識別情報を追加 
9. APIキーに名前を付けます（例：Airtable APIキー）。 タイトル ボックスに記入し、要約を記入してください 意味 ご希望の場合はボックス 
10. 選択する APIキー から 親切 セレクタ
11. 貼り付け APIキー に 認証 箱
12. プレス 生成する

不可欠： リクエストを送信するAPIがベアラー検証を必要とする場合は、 トークン 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. プレス 生成する

不可欠： キーと値のペアのキー（例：キー=値の「キー」）のみを追加する必要があります。 クエリパラメータ ボックスに値（API キー）を入力します。値（API キー）は、リクエストのクエリ パラメータに自動的に追加されます。キーはリクエストの送信先の API によって異なるため、詳細についてはサードパーティの API チュートリアルを参照してください。 

APIキーを追加したら、 識別 将来の HTTP リクエストで使用するセレクター。

ユーザー名とパスワードの識別を組み込む方法

一部の API では、API キーではなくユーザー名とパスワードによる検証が必要になる場合があります。Logic で使用されるすべてのユーザー名とパスワードは安全に保管されます。 

不可欠： Webflow は検証を安全に保存しますが、ロジック フローを使用してその検証を送信するサーバーまたはサードパーティ サービスに対しては制御できません。 

ユーザー名とパスワードの識別情報を含めるには:  

1. 公開 合理化パネル > 流れ タブ > 作品編集者 Webflowで
2. を選択 HTTPリクエストを行う キャンバス上のブロックを開くには ブロック設定
3. 選ぶ ユーザー名パスワード から 検証 セレクタ
4. プレス 資格情報を選択 下に 識別
5. プレス 新しい識別情報を追加
6. 識別情報（例：Mailchimp識別情報）に名前を付けます。 タイトル ボックスに要約を追加し、 意味 ご希望の場合はボックス
7. 選ぶ ユーザー名パスワード の中に 親切 セレクタ
8. ユーザー名とパスワードを入力してください ユーザー名 そして パスワード ボックス（ユーザー名とパスワードは外部サービスのもの） 
9. プレス 生成する

ユーザー名とパスワードを入力したら、 識別 将来の HTTP リクエストで使用するセレクター。

リクエスト URL とエンドポイント パス 

各 HTTP リクエストには、リクエストを送信するサーバーを示すリクエスト URL とエンドポイント パスが含まれている必要があります。 

例えば、Mailchimpで新しい連絡先を作成するには、 メールチンプAPI、POSTリクエストを送信します https://{地域}.api.mailchimp.com/3.0/lists/{リストID}/membersこの場合、リクエストURLは https://{地域}.api.mailchimp.com/3.0 エンドポイントパスは /リスト/{リストID}/メンバー. 

リクエストURLとエンドポイントパスを入力できます。 URL 箱の HTTPリクエストを行うブロック設定紫色の「ドットURL ボックスの「 」アイコンをクリックすると、リクエスト URL に動的データ (前のブロックからの出力データなど) を含めることができます。 

注記： リクエスト URL とエンドポイント パスは、リクエストを送信する API によって異なるため、詳細についてはサードパーティの API documentation を参照する必要があります。

問い合わせ文字列

問い合わせ文字列は URL のオプション コンポーネントで、URL の末尾に情報を追加することで、サーバーとの間で情報を中継できます。問い合わせ文字列は通常、URL 内の疑問符 (?) の後に表示され、キーと値のペアとして 1 つ以上のパラメータを含めることができます。等号 (=) は各キーと値を分離し (例: key=value)、アンパサンド (&) は複数のパラメータを分割します (例: key1=value1&key2=value2)。これらは検証 (例: クエリ パラメータに API キーを追加する) や動的データ (例: フォーム送信によって生成されたデータ) の転送に利用できます。 

あなたが、 映画データベース API 映画「ホットロッド」の詳細を調べるには、GETリクエストを https://api.themoviedb.org/3/search/movie?api_key={api_key}&query=Hot+Rodこのシナリオでは、 APIキーそして 検索 キーワードは、 {トークン} 実際のAPIトークンの代わりになり、 高速+車 別の値を表します。これらのキーワードと値は 2 つのパラメータを構成し、クエリ文字列をまとめて形成します。 ?token={token}&search=高速+車. 

紫色の「ドット”アイコンをクリックすると URL の分野 HTTPリクエストを構成する ブロック設定、動的データ (例: 以前のブロックからの結果データ) をクエリ パラメータに統合できます。

注記： HTTP リクエストに組み込むパラメータの種類 (ある場合) とその構造は、リクエストを転送する API によって異なります。そのため、この点については外部 API documentation を参照することをお勧めします。 

リクエストテクニック

HTTPリクエストメソッドはリクエストのアクションを記述します。後続のリクエストメソッドは、 HTTPリクエストを構成する ブロック： 

• 得る
• 役職
• 置く
• パッチ
• 消去

得る

活用できるのは 得る リソースを入手または読むためのリクエストテクニック。繁栄 得る リクエストは、要求された情報を含む応答本体を生成します。 

例えば、 得る request は、Mailchimp のサブスクリプション/オーディエンスに関するデータや、Airtable データベース内のすべてのテーブルの列挙を取得するのに適しています。 

役職

の 役職 リクエストテクニックは、外部サービスやデータベースに新しいリソースを作成するのに役立ちます。 役職 リクエストには、構築するリソースのデータを定義するリクエスト本文が必要です。 

Webflowウェブサイトでニュースレターの購読者を集め、Mailchimpリストに送りたいとします。フォーム送信トリガーと HTTPリクエストを構成する 伝えるためのブロック 役職 Mailchimp へのリクエスト。このシナリオのリクエスト本文には、Mailchimp 宛てのフォーム送信のデータがカプセル化されます。 

置く

の 置く リクエストテクニックは、リソースを変更または更新するのに便利です。更新リクエストに適合する既存のリソースがない場合、新しいリソースが作成されます。多くのサードパーティサービスでは、既存のレコードIDまたは一意の識別子をリクエストに含める必要があります。 置く システムが既存のレコードの存在を判定するのではなく、変更するレコードを指定するよう要求します。

不可欠： の 置く リクエストテクニックは 全体 リクエストされたリソースをリクエスト本体のデータと照合します。これは、指定されていない値によって更新されたリソースの現在の値が上書きされることを意味します。これは特定の状況では潜在的な危険です。 セクション 既存のリソースの一部を変更せずに、残りの部分をそのまま保持したい場合は、代わりに PATCH 要求手法が推奨されます。

Airtableの既存のレコードを更新することが目的であれば、 置く Airtable にリクエストを送信し、Airtable からのレコード全体 (つまり、すべてのセル値と現在のレコード ID を含む完全なレイアウト) と、リクエスト本文の意図された変更を追加します。レコードが Airtable にまだ存在しない場合は、リクエストによって新しいレコードが作成されます。レコードがすでに Airtable にあり、リクエスト本文の既存のセル値のいずれかが空のままである場合、リクエストによって既存のレコードが置き換えられます。つまり、以前に入力されたセル値はリクエスト実行後に無効になります。 

パッチ

の パッチ リクエストテクニックは 置く しかし、 パッチ 変更または更新を可能にする 部分 リソース全体ではなく、リソースの一部を更新します。更新するデータは、リクエスト本体にのみ含める必要があります。

例えば、Airtableの既存のレコードの説明属性を他の属性を変更せずに調整する場合、 パッチ レコードIDとレコードの説明のみを含むリクエストを送信できます。 パッチ リクエストはレコードの指定されたフィールドのみを調整し、他の属性はそのまま残します。 

消去 

の 消去 リクエストはリソースを消去するために使用されます。 

例えば、 消去 Mailchimp にオーディエンスの解体を依頼したり、Hubspot に冗長なリード監視からの解放を依頼したりします。

リクエスト記述子

リクエスト記述子は、サーバーが適切に応答できるように、HTTP リクエストに関するコンテキストを生成します。たとえば、GET リクエストでは、リクエスト記述子で必要な応答形式を指定したり、POST リクエストでは転送されるデータの種類を示すことができます。 

注記： HTTP リクエスト内のリクエスト記述子 (存在する場合) は、リクエストが指定されている API によって異なるため、詳細については外部 API documentation を参照することをお勧めします。 

リクエストヘッダーを HTTPリクエストを送信する モジュール: 

1. アクセス HTTPリクエストモジュール設定の送信 > 一般的な > ヘッダー 
2. 「プラス” 記号 
3. ヘッダーの名前と値を指定します

リクエストヘッダーを削除するには、「ごみ”アイコンをクリックします。

リマインダー： 名前と値を入力せずにヘッダーを作成した場合、フローエディターはそれを不明な値として保存します。問題を防ぐために、不明なヘッダーを削除することをお勧めします。これを行うには、「ごみヘッダーの横にある「 」アイコンをクリックします。

データをリクエスト

リクエストデータは、リクエストとともにサーバーに転送する情報です。たとえば、POSTリクエストでは、生成したいエンティティになります。リクエスト本体の存在は、GETリクエストでリソースを取得する場合など、特定のリクエストでは必須ではありません。この場合、本体にコンテンツを指定する必要はありません。 データをリクエスト セクションは HTTPリクエストモジュール設定の送信 > 一般的な リクエスト本体を必要とするメソッド (POST、PUT、PATCH など) を選択する場合。 

リクエスト本文は、JSON (JavaScript Object Notation) を使用して構造化します。JSON は、二重引用符で囲まれ、コロンで区切られたキー/値のペアで構成されるテキストベースのデータ形式です。例: 

「名前」: 「ロッド・キンブル」

リクエスト本体を形成する JSON オブジェクトには、カンマで区切られた複数のキー/値のペアが含まれる場合があります。例: 

{ "名前": "ロッド・キンブル", "職業": "スタントマン" }

重要な： カンマ、コロンの省略、引用符の欠落があるとJSONファイルが無効になり、リクエストが失敗する可能性があります。JSONを手動で解析するのは複雑なため、次のような無料ツールを使用すると、 JSONリント 検証には推奨されます。 

紫色の「ドット”アイコンをクリックすると 本文 (JSON) フィールド。サポートされているデータ型は次のとおりです。 

• 無地
• Eメール
• 電話 
• 番号
• テキストエリア
• チェックkbox
• タイムスタンプ

注記： リクエスト本文に含まれる詳細は、リクエストを送信する API によって異なります。したがって、この情報については、サードパーティ API documentation を参照することが不可欠です。 

認証資格情報の管理

資格情報 (API トークン、ユーザー名、パスワードなど) は、送信中および保存時に暗号化され、Webflow 内に安全に保存されます。資格情報が確立されると、作成者であっても Webflow UI 内で実際の値にアクセスすることはできません。作成された資格情報に割り当てられたユーザー定義の名前のみが表示されます。 

重要な： Webflow は資格情報の安全な保管を保証しますが、ロジック フローを通じて資格情報を受け取るサーバーやサードパーティのサービスは管理しません。 

新しい資格情報の追加

新しい資格情報を導入するには、 ブロック設定 > 認証 > 資格情報を選択 選択して 新しい資格情報を追加資格情報を追加するプロセスは、資格情報の種類 (API トークンやユーザー名とパスワードなど) によって異なります。 

サーバーによって承認されます。「2」で始まるコードは勝利の応答を示します。

200 大丈夫です は、成功した HTTP リクエストに対する標準的な応答ですが、応答はリクエスト メソッドによって異なる場合があります。 201 作成例えば、成功したことに対する最も一般的な返答は 役職 リクエスト。 

成功した応答に関するMDN documentationをご覧ください.

リダイレクト応答

リダイレクト ステータス コードは、クライアントが HTTP 要求を完了するために追加の手順を実行する必要があることを示します。これは、要求に複数の潜在的な応答がある場合、または要求されたリソースの URL が永続的に変更された場合に発生する可能性があります。「3」で始まるコードは、リダイレクト応答を意味します。 

リダイレクト応答に関するMDN documentationを調べる.

クライアントエラー応答

クライアント エラー ステータス コードは、クライアントによってトリガーされた問題が原因で、サーバーがリクエストを処理できないか、処理しないことを示します。これは、リクエスト側 (つまり、ユーザー側) に問題があることを意味します。クライアント エラー ステータス コードは、構文に欠陥があるリクエスト、必要な認証がないリクエスト、存在しないリソースへのリクエストなどに対して発行されることがあります。「4」で始まるコードは、クライアント エラー応答を示します。 

クライアントエラー応答に関するMDN documentationを参照してください。.

サーバーエラー応答

サーバー エラー応答は、サーバーがリクエストを完了できなかったか、完了できないことを示します。これは、サードパーティ サービス側に問題があることを示しています。「5」で始まるコードは、サーバー エラー応答を示します。 

サーバーエラー応答に関するMDN documentationを読んでください.

レスポンスヘッダー

レスポンス ヘッダーは、応答サーバーの詳細、データ タイプ、ホスト アドレスなど、レスポンスの追加コンテキストを含む HTTP ヘッダーです。 

レスポンス本文

HTTP リクエストが成功すると、レスポンス本文には次のいずれかが含まれます。

• クライアントが要求したリソース、または 
• クライアントが要求したアクションのステータスに関する詳細

HTTP リクエストが失敗した場合、レスポンス本文には次の内容が提供される場合があります。

• エラーの原因についてのさらなる洞察、または 
• クライアントがリクエストを完了するために取るべき行動

すべての応答に応答本文が含まれるわけではありません。 

HTTPリクエストブロックのテスト方法

独立してテストできる HTTPリクエストを行う ブロックをワークフローの残りの部分から分離して、トラブルシューティングを効率化します。 

評価するには HTTPリクエストを行う ブロック： 

1. アクセス ロジックパネル > 流れ タブ > フローエディタ 
2. 右クリックして HTTPリクエストを行う キャンバスにブロックして選択する このアクションをテストする、または HTTPリクエストを行う キャンバス上のブロックをクリックして テストを実行する セットアップを完了するには で ブロック設定
3. モーダルメニューウィンドウにサンプルデータを入力する
4. プレス テストを実行する

ワークフローのテストについて詳しく学びます。

HTTPリクエストをテストするための追加リソース

次のような無料サービスもご利用いただけます webhook.サイト または リクエストbin.com HTTP リクエストをテストします。これらのサービスはサンプル API エンドポイントを提供するため、実際にデータを転送せずにリクエストを検証できます。 

活用することもできます 郵便配達員無料の API クライアントを使用して、API エンドポイントを詳しく調べ、HTTP リクエストをテストします。これにより、Logic から外部的にリクエストをデバッグできるようになります。 

FAQとトラブルシューティング

HTTP リクエストが失敗していますが、その理由は不明です。 

応答ステータス コード (および場合によっては応答本文) を利用すると、HTTP 要求が失敗する理由についてより詳しい情報を得ることができます。たとえば、クライアント エラーまたはサーバー エラーが原因で失敗する可能性があります。 

クライアントエラー応答を受信した場合、リクエストに欠陥がある可能性があります。次のような補助ツールを使用してJSONを検証すると効果的です。 JSONリント 構文エラーを修正します。 

個別にテストすることもできます HTTPリクエストを行う ブロックを使用すると、トラブルシューティングが簡単になります。HTTP リクエスト ブロックをテストする方法を学びます。 

HTTP リクエストが失敗する理由がまだ不明な場合は、追加のサポートとリソースを得るために、リクエストを送信しているサードパーティ サービスにお問い合わせください。 

HTTPリクエストブロック自体に問題が発生していると思われる場合は、 サポートが必要な場合は、カスタマーサポートチームにお問い合わせください。必ず フローID あなたの提出物と共に。 

PUT と PATCH の違いは何ですか? 

PUTリクエストは、 新鮮な 更新する指定されたリソースが見つからない場合は、リソースを更新しません。また、PUT リクエスト手法では、要求されたリソース全体がリクエスト本文のデータに置き換えられます。つまり、指定されていない値によって、更新するリソースの既存の値が上書きされることになります。これは、シナリオによっては有害となる可能性があります。 

PATCHリクエストを使用すると、 セクション 更新したいデータのみを表示することで、リソースの完全性を維持します。 

他の Workspace メンバーは、私が含めた資格情報 (サードパーティの API キー、ユーザー名、パスワードなど) を表示できますか? 

Workspace メンバーは、資格情報のセグメントを管理、利用、および表示できます。ただし、資格情報が確立されると、その資格情報の元の作成者を含め、誰も Webflow UI で資格情報の実際の値を表示できなくなります。基本的に、Workspace メンバーは、作成された資格情報のユーザー定義名を確認することはできますが、API トークンやユーザー名とパスワードの実際の値にアクセスすることはできません。

Webflow は資格情報をどのように保存および管理しますか? 

資格情報は安全に保存されます。送信中は常に暗号化され、保存中も常に暗号化されます。資格情報が確立されると、その資格情報の元の作成者を含め、誰も Webflow UI で資格情報の実際の値を表示できなくなります。作成された資格情報のユーザー定義名のみを表示できます。 

Webflow は資格情報を安全に保存しますが、ロジック フローを使用して資格情報を送信するサーバーは Webflow によって管理されないことにご注意ください。 

サイトが複製または転送された場合、資格情報はどうなりますか? 

サイトが複製または転送されると、資格情報は保持されません。フローで使用されている資格情報は、サイトが複製または転送された後に再確立する必要があります。