HTTPトリガーを使用すると、HTTPリクエストを使用して関数を呼び出すことができます。 HTTPトリガーは、webサービスの急速な開発などのシナリオで使用できます。 HTTPトリガーを使用する前に、HTTPトリガーの制限と、HTTPトリガーでサポートされるプロトコル (HTTP/HTTPS、WebSocket、gRPCプロトコルなど) の制限を理解していることを確認して、制限の超過による関数エラーを防止してください。 このトピックでは、HTTPトリガーの制限、呼び出し方法、認証方法、およびクロスオリジンリソース共有 (CORS) リクエストの処理について説明します。
注意事項
[認証方法] が [認証なし] に設定されている匿名HTTPトリガーを使用する場合、ID認証は必要ありません。 この場合、誰でもHTTPリクエストを送信して関数を呼び出すことができます。 これは、URL漏洩につながる可能性がある。 URLの漏洩を避けるために、リクエストヘッダーの
[権限付与]
フィールドを使用して、リクエストの有効性を確認できます。 詳細については、「署名認証」をご参照ください。仮想IPアドレス (VIP) ローテーションメカニズムに注意してください。
システムのレジリエンスとサービスの安定性を高めるために、Function ComputeはVIPローテーションメカニズムを実装しています。 具体的には、Function ComputeのHTTPトリガーのパブリックエンドポイントと内部エンドポイントに対応するVIPは、時々ローテーションされます。 VIP回転メカニズムは、インフラストラクチャの堅牢性の不可欠な部分を構成します。
したがって、VIPのハードコーディングは、サービス中断を引き起こし得る。 サービスの堅牢性を確保するために、カスタムドメイン名を使用することを推奨します。 VIPの不適切な使用による障害は、Function Computeの補償範囲には含まれません。 VIPが不適切に使用されている場合は、設定を確認し、必要な調整を行います。
CNAMEでカスタムドメイン名を使用してFunction Computeにアクセスできます。 詳細については、「カスタムドメイン名の設定」をご参照ください。
制限事項
HTTPトリガーを設定して使用する前に、HTTPトリガーの制限と、HTTP/HTTPS、WebSocket、gRPCプロトコルなど、HTTPトリガーでサポートされるプロトコルの制限に精通していることを確認してください。
トリガーの制限
非webサーバーモードのカスタムコンテナー関数では、HTTPトリガーを作成できません。
関数のHTTPトリガーを設定した後、関数の他のタイプのトリガーを設定することはできません。
バージョンまたはエイリアスごとに、最大で1つのHTTPトリガーしか作成できません。 詳細については、「バージョンの管理」および「エイリアスの管理」をご参照ください。
デフォルトでは、HTTPトリガーによって提供される組み込みドメイン名はテスト専用です。 組み込みドメイン名の安定性は保証されておらず、オンラインサービスに影響を与える可能性があります。 外部オンラインサービスには組み込みドメイン名を使用しないことを推奨します。
説明Webサイトサービスは、ICP登録を取得したドメイン名を使用してのみ提供できます。 カスタムドメイン名を設定し、ドメイン名を関数にバインドしてから、ドメイン名を使用してサービスを提供できます。 詳細については、「カスタムドメイン名の設定」をご参照ください。
HTTP/HTTPSの制限
関数をトリガーするには、GET、POST、PUT、DELETE、HEAD、PATCH、およびOPTIONSのメソッドを使用できます。 HTTPおよびHTTPSプロトコルは、単純なリクエスト /レスポンスシナリオに適しています。 詳細については、「HTTPトリガーの設定と使用」をご参照ください。
HTTPリクエストの制限
x-fc- で始まるカスタムリクエストヘッダー、またはconnectionとkeep-aliveのカスタムフィールドは使用できません。
リクエストが次のいずれかの制限を超えた場合、システムは
400
ステータスコードとInvalidArgument
エラーを返します。ヘッダーサイズ: ヘッダー内のすべてのキーと値の合計サイズは8 KBを超えることはできません。
パスサイズ: 合計サイズにすべてのクエリパラメータが含まれます。 パスの合計サイズは8 KBを超えることはできません。
ボディサイズ: 同期呼び出しリクエストのボディの合計サイズは32 MBを超えることはできません。 非同期呼び出し要求の本体の合計サイズは128 KBを超えることはできません。
HTTP応答の制限
レスポンスヘッダーは、x-fc- で始まるカスタムフィールド、またはconnection、content-length、date、keep-alive、server、upgrade、content-disposition:attachmentのカスタムフィールドをサポートしません。
応答が次のいずれかの制限を超えると、システムは
502
コードとBadResponse
エラーを返します。ヘッダーサイズ: ヘッダー内のすべてのキーと値の合計サイズは8 KBを超えることはできません。
説明セキュリティ上の理由から、Function Computeのデフォルトのドメイン名e aliyuncs.comを使用すると、サーバーはレスポンスヘッダーにcontent-disposition: attachmentフィールドを強制的に追加します。 このフィールドは、ブラウザから返された結果を添付ファイルとしてダウンロードするために使用されます。 この制限を解除する場合は、カスタムドメイン名を使用できます。 詳細については、「カスタムドメイン名の設定」をご参照ください。
WebSocketの制限
GETメソッドを使用して関数をトリガーできます。 WebSocketは、永続的な接続とリアルタイムメッセージングが必要なシナリオに適しています。 詳細については、「WebSocketリクエストに応答する関数のHTTPトリガーの設定」をご参照ください。
ランタイム: カスタムランタイムとカスタムコンテナランタイムのみがWebSocketをサポートしています。
タイムアウト制限: WebSocketリクエストのタイムアウト期間は、関数に対して設定されたタイムアウト期間の影響を受けます。
WebSocketハンドシェイクリクエストのリクエスト制限:
x-fc- で始まるリクエストヘッダーはサポートされていません。
ヘッダーサイズ: ヘッダー内のすべてのキーと値の合計サイズは8 KBを超えることはできません。
パスサイズ: すべてのクエリパラメータを含むパスの合計サイズは、8 KBを超えることはできません。
Body: WebSocketハンドシェイク要求でボディを送信することはできません。 ボディが送信されても、Function Computeはボディを無視します。
WebSocketハンドシェイク要求の応答制限:
レスポンスヘッダーのすべてのキーと値の合計サイズは8 KBを超えることはできません。 それ以外の場合、システムは
502
コードとBadResponse
エラーを返します。WebSocketのデータ送信制限:
WebSocket接続を確立した後、毎回送受信できるパケット (メッセージ) の最大サイズは6 MBを超えることはできません。
gRPCの制限
HTTPトリガーは、gRPCリクエストによってトリガーできます。 gRPCリクエストは、低レイテンシ、高性能、およびProtoBufベースの多言語通信を必要とするシナリオに適しています。 詳細については、「gRPCリクエストで関数を呼び出すHTTPトリガーの設定」をご参照ください。
ランタイム: カスタムランタイムとカスタムコンテナランタイムのみがgRPCをサポートしています。
制限事項
gRPCを使用して関数をトリガーする前に、HTTPトリガーのリクエストメソッドにPOSTメソッドが含まれていることを確認してください。
gRPC呼び出しを開始するには、サブドメイン
fcapp.ru n
またはカスタムドメイン名を使用します。
タイムアウト期間: gRPCリクエストは、関数に対して設定されたタイムアウト期間の影響を受けます。 ストリーミングgRPC接続の最大保持期間は、関数の [実行タイムアウト期間] パラメーターに指定された値を超えることはできません。
gRPCリクエストのデータ送信: gRPCストリーミング接続を確立した後、1つのパケット (メッセージ) で送受信できるデータの最大量は6 MBを超えることはできません。
利点
HTTPトリガーとAPI Gatewayトリガーの両方を使用して、webアプリケーションを作成できます。 次の項目では、HTTPトリガーとAPI Gatewayトリガーの利点について説明します。
HTTPトリガー: カスタムドメイン名をバインドして、さまざまなHTTPアクセスパスをHTTP関数にマッピングできます。 詳細については、「カスタムドメイン名の設定」をご参照ください。
API Gatewayトリガー: API Gatewayトリガーを使用することもできます。 この場合、バックエンドサービスタイプをFunction Compute 2.0に設定し、関数タイプをHTTP Functionに設定し、バックエンドサービスアドレスを設定して同様の機能を実装します。 詳細は、「Function Compute」をご参照ください。
API Gatewayトリガーと比較して、HTTPトリガーは次の利点を提供します。
HTTPトリガーは、開発者が簡単に学習および使用できます。 これにより、デバッグプロセスが簡素化され、開発者はFunction Computeを使用してwebアプリケーションとAPIをすばやく構築できます。
HTTPトリガーを使用して、リクエスト処理を最適化できます。 HTTPトリガーは、効率的な要求および応答形式をサポートします。 リクエストをJSON形式にエンコードまたはデコードする必要はありません。 これにより、パフォーマンスが向上します。
Function Computeの機能とパフォーマンスのテストに慣れているHTTPテストツールを使用できます。
Alibaba Cloud CDNやMNS (Message Service) など、Webhookをサポートする他のサービスにHTTPトリガーを簡単に接続できます。
WebSocketおよびgRPCプロトコルがサポートされています。
呼び出しメソッドInvocation methods
同期呼び出し
同期呼び出し中に、イベントが関数によって処理された後に結果が返されます。 デフォルトでは、HTTPトリガーは同期モードで関数を呼び出します。 詳細については、「同期呼び出し」をご参照ください。
非同期呼び出し
非同期呼び出し中、Function Computeはリクエストを保持し、リクエストの実行が完了するのを待たずにすぐにレスポンスを返します。
非同期呼び出し: HTTP関数がトリガーされると、
"X-Fc-invocation-Type":"Async"
リクエストヘッダーを追加して、リクエストレベルで非同期呼び出しを実装できます。非同期タスク: HTTP関数の非同期タスクモードを設定した後、
"X-Fc-Stateful-Async-Invocation-Id":"g6u ***** iyvhd3jk8s6bhj0hh"
リクエストヘッダーを追加して、非同期タスクの呼び出しIDを設定できます。
リクエストヘッダーの詳細については、「InvokeFunction」をご参照ください。
非同期呼び出しが成功すると、Function Computeはリクエストを受信したことを示す202
コードを返します。 次に、リクエストIDとステートフル呼び出しIDの値は、「X-Fc-リクエスト-Id」: 「80bf7 **** 281713e1」、「X-Fc-ステートフル-非同期呼び出し-Id」: 「7522ba40 **** 1c22e」
形式で返されます。
Function Computeから返されたステータスコードが202
でない場合、非同期呼び出しは失敗します。 失敗した呼び出しの原因の詳細については、「エラー処理」をご参照ください。
特定のシナリオでは、非同期呼び出しリクエストを送信した後、Function Computeの実行を延期することができます。 Function Computeの実行を延期する場合は、x-fc-async-delay
HTTPリクエストヘッダーをコードに追加できます。 ヘッダーの値の範囲は (0,3600) です。 単位は秒です。 Function Computeは、x-fc-async-delay
に指定された期間が経過すると、関数を呼び出します。 詳細については、「延期呼び出し」をご参照ください。
認証
HTTPトリガーの認証を設定できます。 HTTPトリガーの認証を設定した後、関数がリクエストを処理する前に、外部リクエストは認証を通過する必要があります。 HTTPトリガーには、署名認証とJSON Webトークン (JWT) 認証を設定できます。
署名認証
HTTPトリガーに対して署名認証が設定されている場合、割り当てられたAccessKey IDとAccessKeyシークレットを使用してリクエストに署名する必要があります。 AccessKey IDとAccessKeyシークレットは、認証のためにFunction Computeに渡されます。 詳細については、「署名認証」をご参照ください。
署名認証は、高レベルのセキュリティを提供する。 ただし、署名アルゴリズムをクライアントに実装する必要があり、コストが高くなります。 さらに、AccessKey IDとAccessKeyシークレットはクライアントに保存する必要があり、データ漏洩のリスクがあります。 Alibaba Cloud Security Token Service (STS) トークンを使用してこの問題に対処できます。 しかしながら、これは、アーキテクチャの複雑さを増大させる。
JWT認証
JWTは、APIの承認とアクセスのための一般的で安全なメカニズムです。 JWTは、JavaScriptやwebフロントエンドなどのセキュリティの低いクライアントシナリオに適しています。 詳細については、「HTTPトリガーのJWT認証の設定」をご参照ください。
CORSリクエスト処理
デフォルトでは、Function ComputeはHTTP関数へのクロスオリジンアクセスを許可します。 Function Computeでは、関数コードでクロスオリジンリソース共有 (CORS) リクエストのカスタム処理動作を指定することもできます。
シンプルなリクエスト
プリフライト要求は、単純な要求には必要ありません。 関数コードでAccess-Control-Allow-*
で始まるヘッダーを設定して、アクセス制御を簡単に実装できます。 シンプルなリクエストの場合、Function Computeは次のカスタムヘッダーをサポートしています。Access-Control-Allow-Origin
、Access-Control-Allow-headers
、Access-Control-Request-Method
、Access-Control-Max-Age
。
カスタムヘッダーを設定しない場合、Function Computeは次のレスポンスヘッダーを入力します。
Access-Control-Allow-Origin
: リクエストのオリジンヘッダー。Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers
: Function Computeの特定のカスタムヘッダー。
シンプルでないリクエスト
プリフライト要求は、単純でない要求が送信される前に送信される。 ブラウザは、OPTIONSメソッドを使用してプリフライト要求を送信し、関数を呼び出す実際の要求を開始します。 非単純な要求を開始するための規則は、単純な要求を開始するための規則と同じである。 プリフライト要求に対してカスタム応答を指定する場合は、HTTPトリガーにOPTIONSメソッドを追加し、関数コードでOPTIONS要求を処理する必要があります。 具体的には、Access-Control-Allow-*
で始まるヘッダーを設定して、関数のクロスオリジン動作を制御できます。
プリフライト要求の場合、Function Computeは、Access-Control-Allow-Origin
、Access-Control-Allow-headers
、Access-Control-Request-Method
、Access-Control-Max-Age
のカスタムヘッダーをサポートしています。
この例では、Node.jsを使用して、関数コードでプリフライト要求を処理する方法を説明します。
exports.handler = (req, resp, context) => {
console.log('hello world');
if (req.method === 'OPTIONS') {
// Send response to OPTIONS requests
resp.setHeader('Access-Control-Allow-Origin', 'http://www.fc.com')
resp.setHeader('Access-Control-Allow-Methods', 'POST');
resp.setHeader('Access-Control-Allow-Headers', 'Content-Type');
resp.setHeader('Access-Control-Max-Age', '3600');
resp.setStatusCode(204)
resp.send('');
} else {
resp.send("hello world");
}
}
よくある質問
関連ドキュメント
HTTPトリガで構成された関数のハンドラは、イベント関数のハンドラとは異なる。 ハンドラーが正しく構成されていることを確認します。 詳細については、以下のトピックをご参照ください。