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
ベストアンサー1
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ヘッダーに " " を追加して、システム資格情報を使用してエンドポイントにアクセスします。受信側システムは、システム資格情報がユーザーに代わって操作する権限を持っていることを検証し、次にユーザーがアクションを実行する権限を持っていることを検証します。