現時点でAPIに取り組んでおり、APIキーを送信するのに最適な場所がどこにあるべきかについて意見を収集したかっただけです。URLに入れるべきではないことを知っています。これにより、リクエストヘッダーまたはメッセージ本文が残ります。
それをヘッダーに入れると、すべてのサービスで使用できる一般的なメソッドを引き出すことができますが、私が渡された仕様はそれを本体に必要としています(つまり、JSON文字列でPOST本体のシリアル化されたオブジェクト)。
現時点でAPIに取り組んでおり、APIキーを送信するのに最適な場所がどこにあるべきかについて意見を収集したかっただけです。URLに入れるべきではないことを知っています。これにより、リクエストヘッダーまたはメッセージ本文が残ります。
それをヘッダーに入れると、すべてのサービスで使用できる一般的なメソッドを引き出すことができますが、私が渡された仕様はそれを本体に必要としています(つまり、JSON文字列でPOST本体のシリアル化されたオブジェクト)。
回答:
HTTPには、Authorization
そのためのヘッダーがあります。
通常、ユーザーの資格情報を提供するために使用されますが、APIの場合、クライアントのIDと対応するAPIキーを含めることができます。
いくつかの利点があります。
さまざまなフレームワークからのサポート。多くのフレームワークでは、Authorization
認証を行うためにヘッダーが必要です。それを使用しないと、これらのフレームワークにカスタム値を提供するための追加コードを強制的に作成します。
さまざまなツールからのサポート。たとえば、CURL。
チームに参加している新しい開発者(またはAPIの新しいクライアントを設計している開発者)からの「WTFは、このAPIキーをどこで検索/配置しますか?!」
その後、のようなHTTPステータスコードの定義を使用することができ401 Unauthorized
、そのために:
応答には、WWW-Authenticateヘッダーフィールドを含める必要があります[...]クライアントは、適切なAuthorizationヘッダーフィールドを使用してリクエストを繰り返すことができます。
リクエストの本文に移動すると、すぐに痛みを感じるようになります。ほとんどのフレームワークとツールは、リクエストに本文を追加することをあまり簡単にしないため、APIが必要以上に難しくなる可能性があります。