REST API：カスタムHTTPヘッダーとURLパラメーター
REST APIのリクエスト部分でカスタムHTTPヘッダーを使用するのはいつですか？
例：
使用しますか
GET /orders/view
(custom HTTP header) CLIENT_ID: 23
の代わりに
GET /orders/view/client_id/23 or
GET /orders/view/?client_id=23
URLはリソース自体を示します。 「クライアント」は、実行可能なリソースであるため、ベースURL /orders/view/client/23の一部である必要があります。
パラメータは、リソースへのアクセスをパラメータ化するためのものです。これは特に、投稿と検索に関係します：/orders/find?q=blahblah&sort=foo。パラメーターとサブリソースの間に細かい線があります：/orders/view/client/23/active versus /orders/view/client/23?show=active。サブリソーススタイルを推奨し、検索用のパラメーターを予約します。
各エンドポイントは（ニーモニックをマングルするために）状態転送を表すため、カスタムヘッダーは、リソースの名前（url）、リソースの状態（本体）、またはパラメーターを直接含まないものにのみ使用する必要がありますリソースに影響します（パラメーター）。これにより、カスタムヘッダーのリクエストに関する真のメタデータが残ります。
HTTPには、必要なほとんどすべてをカバーする非常に幅広いヘッダーがあります。カスタムヘッダーが表示されるのは、ユーザーに代わって動作するシステム間リクエストです。プロキシシステムはユーザーを検証し、「X-User: userid」をヘッダーに追加し、システム資格情報を使用してエンドポイントにアクセスします。受信側システムは、システム資格情報がユーザーに代わって動作することを許可されていることを検証し、ユーザーがアクションを実行することを許可されていることを検証します。
いつREST APIのリクエスト部分で... HTTPヘッダーを使用しますか？
認証：GUID、基本認証、カスタムトークンなど。たとえば、 ユーザー名/パスワードの代わりにREST apiのGUIDトークンを使用した基本認証
PCI-DSSまたはその他のセキュリティルールの対象となるドメイン間でトークンまたはその他の認証のような情報の受け渡しに関与する場合は、一部の規制では、明示的に認証要素を（ブラウザの履歴、プロキシログなど）。
カスタムヘッダーには次の利点があります。
- ネットワークツール/スクリプト（認証、メタ情報など）で簡単に読み取ることができます。
- セキュリティ関連のものからURLを解放します（ブラウザ/プロキシキャッシュではなく、より安全です）
- URLをクリーンに保ちます：リソースのキャッシュを改善します
標準または慣例により情報を渡す他の方法がない場合にのみ、カスタムヘッダーを使用します。 Darren102は、その値を渡す典型的な方法を説明しています。 Apiは、カスタムヘッダーを使用した典型的なパターンを使用することで、より使いやすくなりますが、それらを使用するケースがないと言うのではなく、それらが最後の手段であり、HTTP仕様でまだ処理されていないものである必要があります。
RESTの標準はありませんが、受け入れられる方法は
GET /orders/view/23
カスタムヘッダーを使用せず、したがって23 afterビューはIDであると想定されるため、IDを取得して、その情報のみを生成する関数を使用できます。
プロキシがそれらを渡すかどうかわからないので、カスタムヘッダーは使用しません。 URLベースの方法です。
GET/orders/view/client/23
間違いなくOK：
GET /orders/view/client_id/23 or
GET /orders/view/?client_id=23
またOK：
GET /orders/view/23 or
これも大丈夫だと思います：
POST /orders/view
(custom HTTP header) CLIENT_ID: 23
Enveloping は良い習慣ではないことを考慮して、カスタムヘッダーを使用して、部分的に処理されたリクエストに関する詳細情報を含めることができます。ヘッダーは secure です。