我正在为我公司的数据设计一个公共 API。我们希望应用程序开发人员注册一个 API 密钥，以便我们可以监控使用和过度使用。
由于 API 是 REST，我最初的想法是将此密钥放在自定义标头中。这就是我看到谷歌、亚马逊和雅虎的做法。另一方面，我的老板认为如果密钥只是 URL 的一部分，那么 API 更易于使用，等等。“ http://api.domain.tld/longapikey1234/resource ”。我想对此有话要说，但它违反了 URL 作为您想要的简单地址的原则，而不是您想要它的方式或原因。
您认为将密钥放在 URL 中是否合乎逻辑？或者，如果为某些数据编写一个简单的 javascript 前端，您宁愿不必手动设置 HTTP 标头吗？
它应该放在 HTTP 授权标头中。规范在这里https://www.rfc-editor.org/rfc/rfc7235
If you want an argument that might appeal to a boss: Think about what a URL is. URLs are public. People copy and paste them. They share them, they put them on advertisements. Nothing prevents someone (knowingly or not) from mailing that URL around for other people to use. If your API key is in that URL, everybody has it.
最好在标头中使用 API Key，而不是在 URL 中。
如果从浏览器尝试，URL 会保存在浏览器的历史记录中。这是非常罕见的情况。但是当后端服务器记录所有 URL 时，问题就来了。它可能会暴露 API 密钥。
有两种方式，你可以在 header 中使用 API Key
基本授权：
条纹示例：
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
我不会将密钥放在 url 中，因为它确实违反了这个松散的“标准”，即 REST。但是，如果您这样做了，我会将其放在 url 的“用户”部分。
例如：http://me@example.com/myresource/myid
这样，它也可以作为带有基本身份验证的标头传递。
在参数中传递 api 密钥使客户端难以对其 API 密钥保密，他们往往会定期泄露密钥。更好的方法是在请求 url 的标头中传递它。您可以在代码中设置 user-key 标头。为了测试您的请求网址，您可以通过将用户密钥标头设置为您的 api-key 来使用谷歌浏览器中的 Postman 应用程序。