回答:
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し、ヘッダーに「」を追加し、システム認証情報を使用してエンドポイントにアクセスします。受信側システムは、システム資格情報がユーザーに代わって動作することを承認されていることを検証してから、ユーザーがアクションを実行することを承認されていることを検証します。
カスタムヘッダーには次の利点があります。
標準または規則で情報を渡す方法が他にない場合のみ、カスタムヘッダーを使用します。Darren102は、その値を渡す一般的な方法を説明しています。APIは、カスタムヘッダーを使用して典型的なパターンとversを使用することにより、はるかに親しみやすくなります。つまり、それらを使用するケースがないわけではなく、それらが最後の手段であり、HTTP仕様でまだ処理されていないものである必要があります。
REST APIのリクエスト部分で... HTTPヘッダーを使用するのはいつですか？
認証：GUID、基本認証、カスタムトークンなど。たとえば、 ユーザー名/パスワードの代わりにREST APIのGuidトークンを使用した基本認証
PCI-DSSまたはその他のセキュリティルールでカバーされるドメイン間でトークンやその他の認証のような情報を渡すことに関与する場合、一部の規制では認証要素を明示的に再生できないURLから除外する必要があるため、パラメータを埋める必要がある場合があります（からブラウザの履歴、プロキシログなど）。
プロキシがそれらを渡すかどうかがわからないので、カスタムヘッダーは使用しません。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