会社のデータに対してパブリックAPIを設計しています。アプリケーション開発者にAPIキーにサインアップしてもらい、使用と過剰使用を監視できるようにします。
APIはRESTであるため、最初に考えたのは、このキーをカスタムヘッダーに配置することです。これは、Google、Amazon、Yahooがそれを行うのを見た方法です。一方、上司は、キーがURLの一部にすぎない場合など、APIの方が使いやすいと考えています。 " http://api.domain.tld/longapikey1234/resource " 。そのために何か言いたいことがあると思いますが、それはあなたが望む方法や理由ではなく、あなたが望むものの単純なアドレスとしてのURLの原則に違反しています。
キーをURLに入れるのは理にかなっていますか?または、いくつかのデータに単純なJavaScriptフロントエンドを書き込む場合、HTTPヘッダーを手動で設定する必要はありませんか?
HTTP Authorizationヘッダーに配置する必要があります。仕様はこちら https://tools.ietf.org/html/rfc7235
上司にアピールするような議論が必要な場合:URLについて考えてください。 URLは公開されています。人々はそれらをコピーして貼り付けます。彼らはそれらを共有し、広告に載せます。他の人が使用するために誰かがそのURLを(知っているかどうかに関係なく)郵送することを妨げるものは何もありません。 APIキーがそのURLにある場合、誰もが持っています。
URLではなくヘッダーでAPIキーを使用することをお勧めします。
URLがブラウザーから試行されると、ブラウザーの履歴に保存されます。非常にまれなシナリオです。ただし、バックエンドサーバーがすべてのURLをログに記録するときに問題が発生します。 APIキーが公開される場合があります。
2つの方法で、ヘッダーでAPIキーを使用できます
基本認証:
ストライプの例:
curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:
curlは-uフラグを使用して基本的な認証資格情報を渡します(APIキーの後にコロンを追加すると、パスワードを要求されなくなります)。
カスタムヘッダー
curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users
RESTであるこのゆるい「標準」に違反するため、キーをURLに入れません。ただし、そうする場合は、URLの「ユーザー」部分に配置します。
例: http://[email protected]/myresource/myid
このように、basic-authを使用してヘッダーとして渡すこともできます。
aPIキーをパラメーターに渡すと、クライアントがAPIkeysを秘密にすることが難しくなり、定期的にキーを漏洩する傾向があります。より良い方法は、リクエストurlのヘッダーに渡すことです。コードにuser-keyヘッダーを設定できます。リクエストURLをテストするには、ユーザーキーヘッダーをAPIキーに設定して、GoogleのPostmanアプリchromeを使用できます。