HTTP リクエストを用いて関数を呼び出します。この手法は、Web サービスや類似アプリケーションを迅速に構築する場合に最適です。開始前に、以下の事項をご確認ください:HTTP/HTTPS トリガーの使用制限、同期および非同期呼び出し方法、および認証・権限付与・オリジン間リソース共有(CORS)の設定方法。本トピックではこれらの内容について説明し、よくある質問にもお答えします。
重要なお知らせ
-
匿名トリガーのセキュリティリスク:HTTP トリガーの設定時に認証方法を認証不要に設定すると、本人確認が行われません。誰でも HTTP リクエスト経由でご利用の関数を呼び出すことができ、URL の漏洩リスクが高まります。カスタム権限付与を実装するには、アプリケーションコード内で
Authorizationリクエストヘッダーを検証してください。詳細については、「HTTP トリガー向け署名認証の設定」をご参照ください。 -
APK ダウンロード制限:国家サイバーセキュリティ規制への準拠のため、2024 年 6 月 10 日以降、新規作成の HTTP トリガーでは、パブリックネットワークエンドポイント経由での APK ファイル(MIME タイプ:
application/vnd.android.package-archive)のダウンロードが禁止されます。リクエストに対しては HTTP ステータスコード 400 が返されます。詳細については、「HTTP トリガーのパブリックエンドポイントが .apk ファイルを正しく返すようにする方法」をご参照ください。 -
VIP のローテーション:Function Compute は、システムの耐障害性およびサービスの安定性を向上させるために仮想 IP アドレス(VIP)をローテーションします。HTTP トリガーのパブリックまたはプライベートエンドポイントに関連付けられた VIP は定期的に変更されます。VIP をハードコーディングすると、サービス中断が発生する可能性があります。安定したビジネス運用を維持するには、カスタムドメイン名をご利用ください。VIP の不適切な使用により発生した障害は、Function Compute のサービスレベルアグリーメント(SLA)の適用対象外となります。
カスタムドメイン名を CNAME 設定でご使用ください。詳細については、「カスタムドメイン名の設定」をご参照ください。
制限事項
トリガーの制限
-
各バージョンまたはエイリアスにつき、HTTP トリガーは最大 1 つまで作成できます。詳細については、「バージョン管理」および「エイリアス管理」をご参照ください。
-
組み込みドメイン名はテスト専用です。その安定性が保証されていないため、本番環境向けサービスには使用しないでください。
説明Web サイト形式のサービスをパブリックにホストする場合は、ICP 登録済みのカスタムドメイン名をご利用ください。公開前に、ドメイン名を関数にバインドしてください。詳細については、「カスタムドメイン名の設定」をご参照ください。
HTTP/HTTPS プロトコルの制限
Function Compute では、GET、POST、PUT、DELETE、HEAD、PATCH、OPTIONS リクエストを用いた関数呼び出しがサポートされています。これらはシンプルなリクエスト/応答シナリオに適しています。詳細については、「HTTP トリガーの設定」をご参照ください。
-
HTTP リクエストの制限
-
x-fc- で始まるカスタムリクエストヘッダーはサポートされていません。また、以下のカスタムヘッダーもサポートされていません:
-
connection
-
keep-alive
-
-
リクエストが以下のいずれかの制限を超えると、Function Compute は HTTP ステータスコード
400およびエラーコードInvalidArgumentを返します。-
ヘッダーのサイズ:すべてのヘッダーのキーと値の合計サイズは 8 KB を超えてはなりません。
-
パスのサイズ:クエリパラメーターを含むパス全体のサイズは 4 KB を超えてはなりません。
-
ボディのサイズ:同期呼び出しの場合、リクエストボディは 32 MB を超えてはなりません。非同期呼び出しの場合は、「関数実行のリソース制限」をご参照ください。
-
-
-
HTTP 応答の制限
-
x-fc- で始まるカスタム応答ヘッダーはサポートされていません。また、以下のカスタムヘッダーもサポートされていません:
-
connection
-
content-length
-
date
-
keep-alive
-
server
-
upgrade
-
content-disposition:attachment
説明セキュリティ上の理由から、Function Compute ではデフォルトの Function Compute ドメイン名(aliyuncs.com)を使用している場合、応答ヘッダーに content-disposition: attachment が自動追加されます。これにより、ブラウザが応答を添付ファイルとしてダウンロードするようになります。この動作を無効にするには、カスタムドメイン名を設定してください。詳細については、「カスタムドメイン名の設定」をご参照ください。
-
-
応答が以下の制限を超えると、Function Compute は HTTP ステータスコード
502およびエラーコードBadResponseを返します。-
ヘッダーのサイズ:すべてのヘッダーのキーと値の合計サイズは 8 KB を超えてはなりません。
-
-
API Gateway との比較
HTTP トリガーおよび API Gateway トリガーの両方とも、Web アプリケーションの構築をサポートしています。以下のように使い分けてください:
-
HTTP トリガー:カスタムドメイン名をバインドすることで、異なる HTTP パスを HTTP 関数にマップできます。詳細については、「カスタムドメイン名の設定」をご参照ください。
-
API Gateway トリガー:API Gateway をバックエンドサービスとして Function Compute と併用することもできます。詳細については、「Function Compute を API のバックエンドサービスとして使用する」をご参照ください。
API Gateway トリガーと比較して、HTTP トリガーには以下のような利点があります:
-
開発者の学習時間を短縮し、デバッグを簡素化します。開発者が Function Compute を用いて Web アプリケーションおよび API をより迅速に構築できるようになります。
-
リクエスト処理ステップを削減します。HTTP トリガーは JSON エンコーディング/デコーディングを伴わない効率的なリクエストおよび応答フォーマットをサポートしており、パフォーマンスが向上します。
-
Familiar な HTTP テストツールを活用して、Function Compute の機能およびパフォーマンスを検証できます。
-
CDN の origin fetch や Simple Message Queue (formerly MNS) など、Webhook 対応の他のサービスとの統合が容易です。
呼び出し方法
同期呼び出し
同期呼び出しでは、関数がイベントを処理し、即座に結果を返します。HTTP トリガーはデフォルトで同期呼び出しを使用します。詳細については、「同期呼び出し」をご参照ください。
非同期呼び出し
非同期呼び出しでは、Function Compute がリクエストを永続化し、関数の実行完了を待たずに即座に応答を返します。
-
非同期呼び出し:リクエストヘッダーに
"X-Fc-Invocation-Type":"Async"を追加することで、リクエスト単位の非同期呼び出しを有効化できます。 -
非同期タスク:HTTP 関数に対して非同期タスクを設定した後、リクエストヘッダーに
"X-Fc-Async-Task-Id":"g6u*****iyvhd3jk8s6bhj0hh"を追加して呼び出し ID を指定します。
リクエストヘッダーの詳細については、「関数の呼び出し」をご参照ください。
非同期呼び出しが成功すると、Function Compute は HTTP ステータスコード 202(リクエストが受理されたことを示す)を返します。また、応答ヘッダー内にリクエスト ID も返され、例: "X-Fc-Request-Id": "80bf7****281713e1" となります。
Function Compute が 202 以外のステータスコードを返した場合、呼び出しは失敗しています。失敗の原因については、「再試行メカニズム」をご参照ください。
認証および権限付与
Function Compute では、HTTP トリガーに対する認証および権限付与がサポートされています。外部ユーザーが HTTP トリガー経由でご利用の関数にアクセスするには、Function Compute の認証および権限付与チェックを通過する必要があります。サポートされている認証方式は以下のとおりです:
CORS リクエスト処理
デフォルトでは、Function Compute がご利用の関数へのクロスオリジンリクエストを許可しています。また、関数コード内でクロスオリジン(CORS)リクエストの処理方法をカスタマイズすることも可能です。
単純なリクエスト
単純なリクエストではプレフライトリクエストが送信されないため、関数コード内で Access-Control-Allow-* で始まるヘッダーを直接設定することで、シンプルなアクセス制御を実装できます。単純なリクエストに対して、Function Compute は以下のカスタムヘッダーをサポートしています:Access-Control-Allow-Origin、Access-Control-Allow-Headers、、および Access-Control-Max-Age。
カスタムヘッダーを設定しない場合、Function Compute は対応するリクエストヘッダーに基づき、以下の応答ヘッダーをデフォルトで設定します:
-
Access-Control-Allow-Origin:リクエストの Origin ヘッダー。 -
Access-Control-Allow-Credentials:デフォルト値はtrueです。 -
Access-Control-Expose-Headers:Function Compute が定義するヘッダー。
単純ではないリクエスト
単純ではないリクエストでは、実際のリクエストの前にプレフライトリクエストが送信されます。単純ではないリクエストには、1 回の OPTIONS メソッド呼び出しと 1 回の実際の関数呼び出しが含まれます。実際のリクエストのルールは、単純なリクエストの場合と同じです。プレフライト応答をカスタマイズするには、HTTP トリガーに OPTIONS メソッドを追加し、関数コード内で OPTIONS リクエストを処理します。Access-Control-Allow- で始まる応答ヘッダーを設定して、クロスオリジン動作を制御します。
プレフライトリクエストに対して、Function Compute は以下のカスタマイズ可能なヘッダーをサポートしています:Access-Control-Allow-Origin、Access-Control-Allow-Headers、Access-Control-Allow-Methods、および Access-Control-Max-Age。
たとえば、Node.js ランタイムコードでプレフライトリクエストを処理する方法は以下のとおりです:
exports.handler = (event, context,callback) => {
console.log('hello world');
const method = JSON.parse(event).requestContext.http.method;
if (method === 'OPTIONS') {
// プレフライトリクエストを処理するための応答ヘッダーを設定
const fcResponse = {
'statusCode': 204,
'headers': {
'Access-Control-Allow-Origin': 'http://www.fc.com',
'Access-Control-Allow-Methods': 'POST',
'Access-Control-Allow-Headers': 'Content-Type, Authorization',
'Access-Control-Max-Age':'3600'
},
'body': 'hello world'
};
callback(null, fcResponse);
} else {
callback(null, {
'statusCode': 500,
'body': 'hello world'
});
}
};
API 構成 CORS
API 構成 CORS は現在、招待プレビューとして提供されています。有効化するには、「お問い合わせ」より Alibaba Cloud アカウント ID(UID)をご提供ください。
機能の概要
API 構成 CORS は、Function Compute(FC)が提供するゲートウェイ層の機能です。関数コード内に CORS ロジックを記述することなく、HTTP トリガーまたはカスタムドメイン名上で直接 CORS ポリシーを設定できます。
主なメリット
-
コードの簡素化:CORS ロジックをビジネスロジックから分離できます。コアのビジネスロジックの実装に集中できます。
-
コスト削減:ゲートウェイが OPTIONS プレフライトリクエストに直接応答します。関数インスタンスは起動しないため、実行時間費用を節約できます。
-
一元管理:トリガーまたはドメインレベルでポリシーを設定できるため、マルチサービスの管理が容易になります。
-
応答速度の向上:ゲートウェイがプレフライト結果を直接返すため、レイテンシーが低減します。
適用範囲
-
API バージョン:FC 3.0 関数(API バージョン:2023-03-30)のみ対応。
-
アクセス方法:HTTP トリガー(組み込みテストドメインを含む)またはバインド済みのカスタムドメイン名。
設定方法
トリガーの更新 API または カスタムドメイン名の更新 API を使用して設定します。
CORS 設定パラメーター
|
パラメーター名 |
型 |
説明 |
デフォルト値 |
制約または制限 |
|
allowOrigins |
配列 |
リソースへのアクセスを許可するオリジンのリスト。 |
- |
最大 100 個。各項目は 256 文字を超えてはなりません。 |
|
allowMethods |
配列 |
許可される HTTP メソッドのリスト。 |
トリガーメソッド |
|
|
allowHeaders |
配列 |
ブラウザから許可されるカスタムリクエストヘッダー。 |
- |
最大 50 個。 |
|
exposeHeaders |
配列 |
ブラウザからのアクセスを許可する応答ヘッダーのフィールド。 |
システムデフォルト |
最大 50 個。 |
|
allowCredentials |
ブール値 |
クロスオリジンリクエストにおいて、認証情報(Cookie など)を許可するかどうか。 |
false |
|
|
maxAge |
整数 |
プレフライト(OPTIONS)応答のキャッシュ期間(秒単位)。 |
3600 |
有効範囲:0 ~ 86400。 |
allowOrigins の値:
-
ワイルドカード
*:すべてのオリジンを許可(ただしallowCredentialsがfalseの場合のみ)。 -
ワイルドカード
https://*:「https://」で始まるすべてのオリジンを許可します。 -
特定のドメイン:たとえば
https://example.com。 -
複数のドメイン:配列として指定(例:
["https://example.com", "https://app.example.com"])。 -
サブドメインワイルドカード(例:
https://*.example.com)はサポートされていません。
allowMethods の値:
-
標準 HTTP メソッド:
GET、POST、PUT、DELETE、PATCH、HEAD。 -
ワイルドカード
*:すべての HTTP メソッドを許可。 -
サポートされていない
OPTIONS:プレフライトリクエストのため、OPTIONS メソッドはシステムが自動的に処理します。
リクエスト処理ロジック
API 構成 CORS を有効化すると、ゲートウェイはリクエストの種別に応じて処理を行います:
1. プレフライトリクエスト(OPTIONS)
ブラウザが単純ではないリクエストのプレフライトリクエストを送信すると、ゲートウェイは Origin、Access-Control-Request-Method、および Access-Control-Request-Headers ヘッダーを検証します:
-
検証が成功した場合:HTTP ステータスコード
204 No Contentを返し、設定済みの CORS 応答ヘッダーを挿入します。関数は起動しません。 -
検証が失敗した場合:
-
オリジンは一致するが、他のヘッダーが一致しない場合:ゲートウェイが基本的な CORS ヘッダーを設定します。
-
オリジンが一致しない場合:CORS ヘッダーは設定されません。
-
リクエストは関数インスタンスに転送されます。
-
2. 単純なリクエスト(GET、POST、HEAD など)
ゲートウェイは Origin ヘッダーのみを検証します:
-
検証が成功した場合:
Access-Control-Allow-Originおよびその他の CORS ヘッダーを応答に挿入し、リクエストを関数の実行のために転送します。 -
検証が失敗した場合:CORS ヘッダーは挿入されませんが、リクエストは関数の実行のために転送されます。
互換性および優先度
同一パスに対して複数の CORS 処理方法が適用される場合があります。優先度順(高い順)は以下のとおりです:
-
API 構成 CORS:有効化されている場合、ゲートウェイはまずこのロジックを適用します。
-
デフォルト CORS:API 構成 CORS が無効の場合、ゲートウェイは組み込みのデフォルトクロスオリジンエコーを使用します。
-
関数定義 CORS:関数が返すヘッダーは、上記の結果とマージ(追加)され、互換性が確保されます。
各アプローチの比較
|
機能 |
API 構成 CORS(推奨) |
デフォルト CORS |
ユーザー定義 CORS(コード) |
|
プレフライトリクエストの課金対象ですか? |
課金対象外(ゲートウェイでブロック) |
課金対象となる可能性あり |
課金対象(関数が起動) |
|
コードへの侵入 |
なし |
なし |
高 |
|
対応する API バージョン |
FC 3.0 のみ |
すべてのバージョン |
すべてのバージョン |
|
設定の複雑さ |
低(一度の設定) |
設定不要 |
高(OPTIONS メソッドを処理する必要あり) |
よくある質問
Q1:allowMethods に OPTIONS を含めるように設定した後、API 呼び出しが失敗するのはなぜですか?
A:設計上、OPTIONS メソッドは Function Compute ゲートウェイによって自動的に管理されます。OPTIONS を corsConfig の allowMethods リストに手動で追加しないでください。システムがすべてのプレフライトリクエストを自動的に処理します。
Q2:正常に設定した後も、OPTIONS リクエストが 200 ではなく 204 を返すのはなぜですか?
A:担当チームから「招待プレビュー」の権限が付与されているかをご確認ください。インターセプションプラグインが完全に有効化されていない場合、ゲートウェイは「デフォルト CORS」ロジック(200 を返し、関数に転送)にフォールバックします。
Q3:allowOrigins でサブドメインワイルドカード(例:*.example.com)を使用できますか?
A:サブドメインのあいまい一致はサポートされていません。allowOrigins 配列に必要な第 2 レベルドメインをすべて明示的にリストアップするか、広範なマッチングには https://* をご使用ください。
Q4:関数コードでも CORS ヘッダーを書き込む場合、競合は発生しますか?
A:競合は発生しません。ゲートウェイが生成したヘッダーは、関数が返すヘッダーとマージされます。重複するヘッダーがある場合、ブラウザは通常、最初の値または標準準拠の値を使用します。これにより、既存のアプリケーションがスムーズな移行中に中断されることはありません。