将API密钥放在标题或url中
我正在为公司的数据devise一个公共API。 我们希望应用程序开发人员注册一个API密钥，所以我们可以监视使用和过度使用。
由于API是REST，我最初的想法是把这个键放在一个自定义的头文件中。 我就是这样看到谷歌，亚马逊和雅虎这样做的。 另一方面，我的老板认为，如果密钥简单地成为URL的一部分，则API更易于使用，例如“http：//api.domain.tld/longapikey1234/resource”。 我猜这有些事情要说，但它有点违反了URL的原则，只是简单地说明你想要的东西，而不是如何或为什么你想要它。
你会发现把密钥放在URL中是合乎逻辑的吗？ 或者，如果将一个简单的JavaScript前端写入某些数据，您是不是必须手动设置HTTP标头？
它应该放在HTTP授权标头中。 规范在这里https://tools.ietf.org/html/rfc7235
如果你想要一个可能会对老板有吸引力的论据：想一下url是什么。 url是公开的。 人们复制并粘贴它们。 他们分享他们，他们把他们放在广告上。 没有任何东西可以阻止某人（明知或不知道）将该URL邮寄给其他人使用。 如果您的API密钥在该URL中，则每个人都有。
最好在头中使用API密钥，而不要在URL中使用。
如果从浏览器中尝试，url会保存在浏览器的历史logging中。 这是非常罕见的情况。 但是当后端服务器logging所有的URL时就会出现问题。 它可能暴露API密钥。
有两种方法，您可以在API头中使用API密钥
基本授权：
条纹示例：
curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2: curl使用-u标志来传递基本的authentication信息（在你的API密钥之后添加一个冒号会阻止它向你询问密码）。
自定义标题
curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users
我不会把关键的url，因为它违反了这个宽松的“标准”是REST。 但是，如果你这样做，我会把它放在url的“用户”部分。
例如： http：//me@example.com/myresource/myid
这样它也可以作为标题传递给basic-auth。
在参数中传递api密钥使得客户端难以保密他们的API密钥，他们往往会定期泄漏密钥。 更好的方法是将它传递到请求url的头部。你可以在你的代码中设置user-key头部。 为了testing您的请求url，您可以在谷歌浏览器中使用Postman应用程序，方法是将用户密钥标题设置为您的api密钥。
