Make HTTP requests

HTTPリクエストとは？

HTTP、またはハイパーテキスト転送プロトコルは、インターネット上でデータを通信するためのプロトコルです。インターネットには多くの異なるサーバにホストされているリソース（例：HTMLファイル、スタイルシート、スクリプト、画像など）が存在します。HTTPリクエストによってこれらのリソースにアクセスできます。

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

ブラウザのアドレスバーに「webflow.com」（または他のURL）を入力すると、ブラウザはサーバにGETリクエストを送信してウェブページを取得し、ブラウザで表示します。GETリクエストは、クライアントがリソースを要求するために使用できるHTTPメソッドの一種です。このレッスンの後半で他の一般的なリクエストメソッド（POST、PUT、PATCH、DELETE）について詳しく学びます。

Logicを使ったHTTPリクエストの作成

Logicの文脈では、APIに対してHTTPリクエストを自動化することができます。API、またはアプリケーションプログラミングインターフェースは、基本的に2つの異なるアプリケーションがお互いに通信できるようにする中間者です。この場合、Logicフローと外部のテックスタック（つまり、サイトの機能を提供するために使用されるツールやサービスの組み合わせ）が対話します。たとえば、Airtableからレコードを要求してフローで使用したり、WebflowサイトからデータをAirtableに送信したりできます。APIを使用してCRUD操作を実行し、アプリを活用することができます。

CRUD操作は、ソフトウェアアプリケーションが実行できるべき4つの基本的な操作を指します。それは、Create（作成）、Read（読み取り）、Update（更新）、Delete（削除）のことです。ユーザーはデータを作成し、データを読み取り（アプリケーションのユーザーインターフェースでデータにアクセスする）、データを更新または編集し、データを削除できる必要があります。Webflow CMSは、CRUD操作が可能なアプリケーションとして考えることができ、そこではCMSアイテムの作成、閲覧（読み取り）、編集（更新）、削除が行えます。

最も一般的なHTTPリクエストメソッドは、CRUD操作に対応しています。

実世界のアナロジーを提供すると、APIは銀行のようであり、CRUD操作は銀行で行えるアクションのようです。銀行を訪れると、利用可能な資金と取引の記録を(読み取り)アクセスでき、口座にお金を(作成)預け入れることができ、口座情報を更新することができ、口座からお金を(削除)引き出すことができます。銀行でこれらのアクションを実行するためには、身分証明書で認証し、何をしたいかを銀行に伝える必要があります。APIとの作業にも同じ原則が適用されます。

始める方法

LogicでHTTPリクエストを作成するには：

1. Logic panel > Flows > Flow editor
2. キャンバスにMake HTTP requestブロックをドラッグします。

HTTPリクエストの構造

HTTPリクエストには、次の要素が必要です：

• リクエストメソッド
• リクエストURLとエンドポイントパス

また、HTTPリクエストには次の要素も任意で含めることができます：

• 認証
• リクエストボディ
• リクエストヘッダー
• クエリストリング

認証

銀行で身分証明書を提示するのと同様に、多くのAPIはリソースを要求する際に自己を識別（認証）する必要があります。認証には3つのオプションがあります：

• なし（認証が不要なAPI用）
• APIトークン
• ユーザー名とパスワード

注意: 要求を送信するAPIに必要な認証資格情報の種類は異なるため、この情報については第三者APIのドキュメントを参照する必要があります。すべてのAPIが同じ方法で設計されているわけではなく、すべての認証形式がすべてのAPIと互換性があるわけではありません。

APIトークン クレデンシャル（認証資格情報）の追加方法

パスワードに類似したAPIトークン（「APIキー」や「アクセストークン」と呼ばれることもあります）は、APIに対してHTTPリクエストを行うサイトまたはアプリケーションを識別します。Logicで使用するすべてのAPIトークンは、安全に保存されます。

重要: Webflowは認証情報を安全な方法で保存しますが、Logicフローを使用してその認証情報を送信するサーバーや第三者サービスに対してWebflowは制御を持っていません。

注意: 要求を送信するAPIの要件に応じて、APIトークンをリクエストヘッダーまたはクエリパラメーターに追加することができます。

リクエストヘッダー

始める前に: 要求を送信するAPIのドキュメントを参照してください。これによってAPIトークンの生成方法と場所、リクエストヘッダーの構造を判断できます。ヘッダーの値（例：Authorization、X-API-Keyなど）は、要求を送信するAPIによって異なります。

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

1. 要求を送信するAPIのAPIトークンをコピーします。
2. WebflowでLogicパネル > フロータブ > フローエディタを開きます。
3. キャンバス上のMake HTTP requestブロックを選択してブロック設定を開きます。
4. AuthenticationドロップダウンからAPIトークンを選択します。
5. Add toドロップダウンからHeaderを選択します。
6. Headerフィールドにヘッダーの値（例：Authorization、X-API-Keyなど）を入力します。
7. Credentialの下にあるSelect a credentialをクリックします。
8. Add new credentialをクリックします。
9. NameフィールドにAPIトークンの名前（例：Airtable APIトークン）を入力し、必要に応じてDescriptionフィールドに説明を追加します。
10. TypeドロップダウンからAPIトークンを選択します。
11. TokenフィールドにAPIトークンを貼り付けます。
12. Createをクリックします。

重要: もしも要求を行うAPIがベアラー認証を必要とする場合、APIトークンの前に「Bearer」という文字列をTokenフィールドに入力する必要があります（例: Bearer {token}）

APIトークンを追加したら、次回のHTTPリクエストで使用するために、Credentialドロップダウンから選択できるようになります。

クエリパラメーターに追加する場合

始める前に: 要求を送信するAPIのドキュメントを参照してください。これによってAPIトークンの生成方法と場所、クエリパラメーターの構造を判断できます。クエリパラメーターに使用されるキー/値のペアは、要求を送信するAPIによって異なります。

APIトークン認証資格情報をクエリパラメーターに追加するには：

1. 要求を送信するAPIのAPIトークンをコピーします。
2. WebflowでLogicパネル > フロータブ > フローエディタを開きます。
3. キャンバス上のMake HTTP requestブロックを選択してブロック設定を開きます。
4. AuthenticationドロップダウンからAPIトークンを選択します。
5. Add toドロップダウンからQuery paramsを選択します。
6. Query parameterフィールドにクエリパラメーターのキー（例: key=value の場合は「key」、api_key=value の場合は「api_key」など）を入力します。
7. Credentialの下にあるSelect a credentialをクリックします。
8. Add new credentialをクリックします。
9. NameフィールドにAPIトークンの名前（例: TMDB APIキー）を入力し、必要に応じてDescriptionフィールドに説明を追加します。
10. TokenフィールドにAPIトークンを貼り付けます。これはキー/値のペアの値となります。
11. Createをクリックします。

重要: キー/値のペア内のキー（例: key=value の中の「key」）だけをQuery parameterフィールドに入力してください。値（つまり、APIトークン）は、リクエストのクエリパラメーターに自動的に追加されます。キーは要求を送信するAPIによって異なるため、この情報については第三者のAPIドキュメントを参照してください。

APIトークンを追加したら、次回のHTTPリクエストで使用するために、Credentialドロップダウンから選択できるようになります。

ユーザー名とパスワードのクレデンシャル（認証資格情報）の追加方法

一部のAPIでは、APIトークンの代わりにユーザー名とパスワードで認証が必要な場合があります。Logicで使用するすべてのユーザー名とパスワードは、安全に保存されます。

重要: Webflowは認証情報を安全な方法で保存しますが、Logicフローを使用してその認証情報を送信するサーバーや第三者サービスに対してWebflowは制御を持っていません。

ユーザー名とパスワードの認証資格情報を追加するには

1. WebflowでLogicパネル > フロータブ > フローエディタを開きます。
2. キャンバス上のMake HTTP requestブロックを選択してブロック設定を開きます。
3. AuthenticationドロップダウンからUsername & passwordを選択します。
4. Credentialの下にあるSelect a credentialをクリックします。
5. Add new credentialをクリックします。
6. Nameフィールドに認証資格情報の名前（例: Mailchimpの認証資格情報）を入力し、必要に応じてDescriptionフィールドに説明を追加します。
7. TypeドロップダウンからUsername & passwordを選択します。
8. UsernameとPasswordのフィールドにユーザー名とパスワードを入力します（ユーザー名とパスワードは外部サービスのものです）。
9. Createをクリックします。

ユーザー名とパスワードを追加したら、次回のHTTPリクエストで使用するために、Credentialドロップダウンから選択できるようになります。

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

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

例えば、Mailchimp APIを使用してMailchimpに新しい連絡先を作成するには、POSTリクエストをhttps://{region}.api.mailchimp.com/3.0/lists/{listID}/membersに送信します。この場合、リクエストURLはhttps://{region}.api.mailchimp.com/3.0であり、エンドポイントパスは**/lists/{listID}/members**です。

リクエストURLとエンドポイントパスは、Make HTTP requestのブロック設定のURLフィールドに入力できます。また、URLフィールドの紫色の「点」アイコンをクリックして、ダイナミックデータ（前のブロックの出力データなど）をリクエストURLに追加することもできます。

注意: リクエストURLとエンドポイントパスは、要求を送信するAPIによって異なりますので、この情報については第三者のAPIドキュメントを参照してください。

クエリ文字列

クエリ文字列は、URLの末尾に情報を追加することで、サーバーと情報をやり取りするためのURLのオプションの一部です。クエリ文字列は通常、URL内の疑問符（?）に続いており、1つ以上のパラメーターをキー/値のペアで含むことができます。等号（=）は各キーと値を区切ります（例: key=value）、アンパサンド（&）は複数のパラメーターを区切ります（例: key1=value1&key2=value2）。これらは認証（例: APIトークンをクエリパラメーターに追加する）やダイナミックデータの送信（例: フォームの送信で生成されたデータ）に使用できます。

例えば、映画『Hot Rod』の詳細情報を検索するためにThe Movie Database APIを使用したいとします。この場合、GETリクエストをhttps://api.themoviedb.org/3/search/movie?api_key={api_key}&query=Hot+Rod**に送信します。この例では、api_keyとqueryはキーであり、**{api_key}**は実際のAPIトークンのプレースホルダー値であり、Hot+Rodは別の値です。これらのキーと値は2つのパラメーターを構成し、クエリ文字列全体を形成します: ?api_key={api_key}&query=Hot+Rod。

Make HTTP requestのブロック設定のURLフィールド内の紫色の「点」アイコンをクリックすることで、ダイナミックデータ（前のブロックからの出力データなど）をクエリパラメーターに追加することができます。

注意: HTTPリクエストに含めるパラメーターのタイプ（あれば）およびその形式は、要求を送信するAPIによって異なるため、この情報については第三者のAPIドキュメントを参照してください。

リクエストメソッド

HTTPリクエストメソッドは、リクエストのアクションを定義します。次のリクエストメソッドは、Make HTTP requestブロックで利用できます。

• GET
• POST
• PUT
• PATCH
• DELETE

GET

GETリクエストメソッドを使用して、リソースを取得または読み取ることができます。成功したGETリクエストは、要求した情報が含まれた**レスポンスボディ**を返します。

例えば、GETリクエストを使用して、Mailchimpのリスト/オーディエンスに関する情報を取得したり、Airtableベース内のすべてのテーブルのリストを取得したりすることができます。

POST

POSTリクエストメソッドを使用して、外部サービスやデータベースに新しいリソースを作成することができます。POSTリクエストには、作成したいリソースのデータを定義するリクエストボディが必要です。

例えば、Webflowサイトでニュースレターの購読者を収集し、それをMailchimpのリストに送信したいとします。フォームの送信トリガーとMake HTTP requestブロックを使用して、フォームの送信データをMailchimpに追加するためにPOSTリクエストを送信するフローを作成できます。この例のリクエストボディは、Mailchimpに追加したいフォームの送信データです。

PUT

PUTリクエストメソッドを使用して、リソースを変更または更新することができます。更新するための一致する既存のリソースが存在しない場合、リクエストは新しいリソースを作成します。多くのサードパーティサービスでは、既存のレコードIDや一意の識別子をPUTリクエストに含めて、レコードが既に存在するかどうかを判断するためのロジックをサービス側で実行する代わりに、レコードを識別するために使用することが求められます。

重要: PUTリクエストメソッドは、リクエストボディのデータでリクエストされたリソース全体を置き換えます。これにより、指定されていない値は、更新するリソースの既存の値を上書きすることに注意してください。これは一部のケースでは破壊的な結果をもたらす可能性があります。既存のリソースの一部だけを更新して、他の部分は変更しない場合は、代わりにPATCHリクエストメソッドを使用することをおすすめします。

例えば、Airtable内の既存のレコードを更新したい場合、AirtableにPUTリクエストを送信し、Airtableからのフルレコード（すべてのセルの値と既存のレコードIDを含む完全なスキーマ）をリクエストボディと共に送信します。既存のレコードがAirtableにすでに存在しない場合、リクエストは新しいレコードを作成します。既存のレコードがAirtableにすでに存在し、リクエストボディの既存のセルの値を空にした場合、リクエストは既存のレコードを上書きします。つまり、以前に埋められていたセルの値はリクエストが完了した後に空になります。

AirtableのレコードのDescriptionフィールドを更新するためのPUTリクエストの例。完全なAirtableレコードのスキーマ（つまり、レコードIDと名前）は、リクエストボディとともに渡され、既存のデータが上書きされないようにします。

PATCH

PATCHリクエストメソッドは、PUTリクエストメソッドに類似していますが、PATCHはリソースの一部を変更または更新することができます。リクエストボディに更新したいデータだけを含める必要があります。

例えば、Airtable内の既存のレコードの説明フィールドを更新し、他の部分のレコードをそのままにしたい場合、PATCHリクエストを送信し、レコードIDとレコードに設定したい説明だけを送信することができます。PATCHリクエストは、レコードの説明フィールドのみを更新し、他のフィールドは変更しません。

AirtableのレコードのDescriptionフィールドを更新するためのPATCHリクエストの例。PATCHリクエストは、リクエストで送信されたレコードの一部のみを更新するため、リクエストボディには説明フィールドだけが含まれます。レコードIDは更新するレコードを識別します。

DELETE

DELETEリクエストを使用して、リソースを削除することができます。

例えば、Mailchimpにオーディエンスを削除するためのDELETEリクエストを行ったり、追跡したくないリードを削除するためにHubspotにDELETEリクエストを行ったりすることができます。

リクエストヘッダー

リクエストヘッダーは、HTTPリクエストに関する文脈情報を提供し、サーバーが適切に応答できるようにします。たとえば、GETリクエストでリクエストヘッダーを使用して、サーバーに対して特定の形式で応答を送信するよう指示することができます。また、POSTリクエストでリクエストヘッダーを使用して、送信するデータの種類をサーバーに伝えることができます。

注意: HTTPリクエストのリクエストヘッダー（あれば）は、リクエストを送信するAPIによって異なるため、この情報についてはサードパーティのAPIドキュメントを参照する必要があります。

Make HTTP requestブロックにリクエストヘッダーを追加するには：

1. Make HTTP requestブロックの設定を開く > 一般 > ヘッダー
2. “追加”アイコンをクリックする
3. ヘッダーの名前と値を入力する

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

注意: ヘッダーを作成する際に、名前と値を入力しない場合、Flowエディターはヘッダーを未定義の値として保存します。エラーを避けるために、未定義のヘッダーを削除することをおすすめします。ヘッダーの横にある“ごみ箱”アイコンをクリックして削除できます。

リクエストボディ

リクエストボディは、リクエストでサーバーに送信するデータです。例えば、POSTリクエストの場合、これは作成したいリソースです。リクエストボディは一部のリクエストにおいてはオプションです。例えば、GETリクエストを使用してリソースを取得する際には、リクエストのボディに特定の情報を指定する必要はありません。Request bodyフィールドは、リクエストボディを使用するメソッド（すなわち、POST、PUT、またはPATCH）を選択した場合に、Make HTTP Request block settings > General に表示されます。

リクエストボディを構造化するためにJSON（JavaScript Object Notation）を使用します。JSONは、ダブルクォートで囲まれたキー/値ペアからなるテキストベースのデータ形式で、コロンで区切られています。例えば：

"Name": "Rod Kimble"

リクエストボディを構成するJSONオブジェクトは、コンマで区切られた複数のキー/値ペアを含むことができます。例：{"Name": "Rod Kimble","Job": "Stuntman"}

重要: たった1つの余分なコンマ、削除されたコロン、または欠落した引用符がJSONファイルを無効にし、HTTPリクエストが失敗する原因になる可能性があります。JSONを手動で解析するのは難しい場合があるため、JSONLintのような無料のツールを使用してJSONを検証することをおすすめします。

リクエストボディ内でフローからのダイナミックデータを使用するには、“Body (JSON)”フィールド内の紫色の“点”アイコンをクリックできます。サポートされるデータ型には以下が含まれます：

• Plain
• Email
• Phone
• Number
• Text Area
• Checkbox
• Timestamp

注意: リクエストボディに含める情報は、リクエストを送信するAPIに依存するため、サードパーティAPIのドキュメントを参照する必要があります。

クレデンシャル（認証情報）の管理方法

認証情報（例：APIトークン、ユーザー名とパスワードなど）はWebflow内で安全に保管され、常に転送時に暗号化され、休止時にも暗号化されます。認証情報が作成されると、その認証情報の元の作成者を含む誰も、Webflow UI内で認証情報の実際の値を見ることはできません。作成された認証情報のユーザー定義の名前のみが表示されます。

重要: Webflowは認証情報を安全に保管しますが、Webflowはロジックフローを使用して認証情報を送信するサーバーやサードパーティサービスに対して制御を持っていません。

新しい認証情報を追加する方法

新しい認証情報を追加するには、Block settings > Authentication > Select a credential を開き、「Add new credential」をクリックします。認証情報のタイプによって追加の方法が異なります（例：APIトークン または ユーザー名とパスワード）。

認証資格情報の更新または置き換え方法

認証資格情報を更新または置き換えるには：

1. Logic panel > Flows tab > Flow editor を開きます
2. キャンバス上のMake HTTP requestブロックを選択してBlock settings を開きます
3. Select a credentialの下にあるCredentialをクリックします
4. Manage credentials をクリックします
5. 更新する認証資格情報を選択します
6. 新しい認証資格情報の値（更新されたAPIキーまたは更新されたユーザー名とパスワード）を入力します
7. 保存をクリックします

注意: パスワードを更新する場合、ユーザー名を再入力する必要があります。逆もまた同様です。

認証資格情報のリンク解除と削除方法

認証資格情報を削除するには、まず認証資格情報を使用しているMake HTTP requestブロックから認証資格情報のリンクを解除する必要があります。

認証資格情報のリンク解除方法：

1. Logicパネル > Flowsタブ > Flowエディターを開きます
2. キャンバス上のMake HTTP requestブロックを選択してブロック設定を開きます
3. 認証資格情報のドロップダウンを開きます
4. 認証資格情報のリンク解除をクリックします

認証資格情報を削除する方法：

1. Logicパネル > Flowsタブ > Flow editorを開きます
2. キャンバス上のMake HTTP requestブロックを選択してBlock settingsを開きます
3. Credentialの下にあるSelect a credentialをクリックします
4. Manage credentialsをクリックします
5. 削除したい認証資格情報を選択します
6. Delete credentialをクリックします
7. 削除確認のモーダルウィンドウでDelete credentialをクリックします

重要: 削除した認証資格情報は復元することはできません。

HTTPレスポンスの構造

ステータスコード

HTTPレスポンスのステータスコードは、サーバーがクライアントのHTTPリクエストに対する応答として発行されます。これらのステータスコードは、リクエストが正常に完了したかどうかを示します。HTTPレスポンスのステータスコードは、以下の5つのカテゴリに分類されます：

• Informational responses
• Successful responses
• Redirection responses
• Client error responses
• Server error responses

Informational responses（情報提供応答）

情報提供ステータスコードは、サーバーがリクエストを受信し理解したことを示し、クライアントにはサーバーの最終的な応答を待つよう伝えます。"1"から始まるコードが情報提供応答を示します。

情報回答に関するMDNの文書をチェックしてください。

Successful responses（成功応答）

成功ステータスコードは、成功したHTTPリクエストを示します。クライアントによって要求されたアクションがサーバーによって受信され、理解され、受け入れられました。"2"から始まるコードが成功応答を示します。

200 OK は成功したHTTPリクエストの標準的な応答ですが、応答はリクエストメソッドによって異なる場合があります。たとえば、201 Created は、成功したPOSTリクエストへの最も一般的な応答です。

Redirection responses（リダイレクト応答）

リダイレクトステータスコードは、クライアントがHTTPリクエストを完了するために追加の手順を踏む必要があることを示します。これは、リクエストに複数の可能な応答がある場合や、要求されたリソースのURLが恒久的に変更された場合に発生する可能性があります。"3"から始まるコードがリダイレクト応答を示します。

クライアントエラー応答

クライアントエラーステータスコードは、サーバーがクライアントの問題によってリクエストを処理できないか、処理しないことを示します。つまり、要求元（つまり、あなた）側に問題があるということです。クライアントエラーステータスコードは、不正な構文で送信されたリクエスト、必要な認証が行われていないリクエスト、存在しないリソースへのリクエストなどに対して送信される可能性があります。"4"から始まるコードがクライアントエラー応答を示します。

Server error responses（サーバーエラー応答）

サーバーエラーステータスコードは、サーバーがリクエストを完了できなかったか、リクエストを処理する能力がないことを示します。これは、第三者のサービス側に問題があることを意味します。"5"から始まるコードがサーバーエラー応答を示します。

レスポンスヘッダー

レスポンスヘッダーは、応答に関する追加のコンテキストを提供するHTTPヘッダーで、応答するサーバーの情報、データ型、ホストアドレスなどが含まれます。

レスポンスボディ

HTTPリクエストが成功した場合、レスポンスボディには以下のいずれかが含まれます：

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

Mailchimpが新しい購読者を作成するためのPOSTリクエストに対する成功したレスポンスボディの例。レスポンスボディには、Mailchimp内の新しい購読者に関する情報が含まれています。

HTTPリクエストが失敗した場合、レスポンスボディは以下の情報を提供するかもしれません：

• エラーの原因に関する詳細な情報、または
• クライアントが要求を完了するために行う必要のあるアクション

すべての応答にはレスポンスボディが含まれるわけではありません。

Make HTTPリクエストブロックをテストする方法

トラブルシューティングを容易にするために、Make HTTPリクエストブロックを他のフローから個別にテストできます。

Make HTTPリクエストブロックをテストするには：

1. Logic panel > Flows tab > Flow editor
2. キャンバス上のMake HTTPリクエストブロックを右クリックし、Test this actionを選択するか、キャンバス上のMake HTTPリクエストブロックを選択し、Block settings内でRun testをクリックし、to complete setupをクリックする
3. モーダルメニューウィンドウにサンプルデータを入力する
4. Run testをクリックする

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

webhook.siteやrequestbin.comなどの無料サービスを使用して、HTTPリクエストをテストすることができます。これらのサービスは、実際にデータを転送せずにリクエストを検証できる例のAPIエンドポイントを提供します。

また、無料のAPIクライアントであるPostmanを使用して、APIエンドポイントを探索し、HTTPリクエストをテストすることもできます。これは、Logicの外でリクエストをデバッグするために役立ちます。

よくある質問とトラブルシューティング

HTTPリクエストが失敗していますが、なぜかわかりません。

HTTPリクエストがなぜ失敗しているのかについての詳細情報は、応答のステータスコード（そして場合によっては応答ボディ）に頼ることができます。たとえば、クライアントエラーやサーバーエラーによって失敗する可能性があります。

クライアントエラーレスポンスを受け取った場合、リクエストが不正な可能性があります。構文エラーを解決するために、JSONLintのような無料ツールを使用してJSONを検証することが役立つかもしれません。

また、トラブルシューティングを容易にするために個々のMake HTTPリクエストブロックをテストすることもできます。Make HTTPリクエストブロックのテスト方法を学ぶ。

それでもなおHTTPリクエストの失敗原因がわからない場合は、リクエストを送信しているサードパーティのサービスに連絡して、追加のサポートとリソースを求めてみてください。

Make HTTPリクエストブロック自体に問題があると思われる場合は、お問い合わせ窓口からカスタマーサポートチームにご連絡ください。提出時には必ずFlow IDを含めてください。

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

PUTリクエストは、指定したリソースが見つからない場合、新しいリソースを作成します。PUTリクエストメソッドはまた、要求されたリソース全体をリクエストボディのデータで置き換えます。つまり、指定されていない値は、更新するリソースの既存の値を上書きします。これは場合によっては破壊的な結果をもたらす可能性があります。

PATCHリクエストでは、更新したいデータのみを渡すことで、リソースの一部を更新できます。

他のワークスペースメンバーは、私が追加したクレデンシャル（例：サードパーティのAPIキー、ユーザー名、パスワード）を見ることができますか？

ワークスペースメンバーは、クレデンシャルの一部を管理し、使用し、表示することができます。ただし、一度クレデンシャルが作成されると、そのクレデンシャルの元の作成者を含めて、WebflowのUIでクレデンシャルの実際の値を誰も見ることはできません。言い換えれば、ワークスペースメンバーは、クレデンシャルの名前を見ることができますが、APIトークンやユーザー名、パスワードの実際の値にアクセスすることはできません。

Webflowはどのようにしてクレデンシャルを保管および取り扱っていますか？

クレデンシャルは安全に保管され、転送時に常に暗号化され、休止時にも常に暗号化されます。一度クレデンシャルが作成されると、そのクレデンシャルの元の作成者を含めて、WebflowのUIでクレデンシャルの実際の値を誰も見ることはできません。クレデンシャルが作成されたときには、ユーザーが定義した名前のみを見ることができます。

ただし、Webflowはクレデンシャルを安全に保管する一方で、Logicフローを使用してクレデンシャルを送信するサーバーには影響を与えることはありません。

サイトがクローンされたり転送された場合、クレデンシャルはどうなりますか？

サイトがクローンされたり転送された場合、クレデンシャルは保持されません。フローで使用されているクレデンシャルは、サイトがクローンまたは転送された後に再作成する必要があります。