我正在为我公司的数据设计一个公共 API。我们希望应用程序开发人员注册 API 密钥，以便我们可以监控使用情况和过度使用情况。
由于 API 是 REST，我最初的想法是将此密钥放在自定义标头中。我看到谷歌、亚马逊和雅虎就是这样做的。另一方面，我的老板认为，如果密钥只是 URL 的一部分，等等，那么 API 会更容易使用。“http://api.domain.tld/longapikey1234/resource”。我想对此有一些话要说，但它违反了 URL 的原则，即您想要什么的简单地址，而不是您想要它的方式或原因。
您认为将密钥放在 URL 中合乎逻辑吗？或者，如果将简单的 javascript 前端写入某些数据，您是否不想手动设置 HTTP 标头？
它应该放在 HTTP 授权标头中。规范在这里https://www.rfc-editor.org/rfc/rfc7235
如果你想要一个可能吸引老板的论点：想想 URL 是什么。 URL 是公开的。人们复制并粘贴它们。他们分享它们，把它们放在广告上。没有什么可以阻止某人（有意或无意）将该 URL 邮寄给其他人使用。如果您的 API 密钥位于该 URL 中，那么每个人都拥有它。
最好在标头中使用 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
在参数中传递 api 密钥会使客户端很难保守其 API 密钥的秘密，他们往往会定期泄漏密钥。 更好的方法是将其传递到请求 url 的标头中。您可以在代码中设置 user-key 标头。 为了测试您的请求 Url，您可以通过将 user-key 标头设置为您的 api-key 来使用 google chrome 中的 Postman 应用程序。
我不会将密钥放在 url 中，因为它确实违反了 REST 这个松散的“标准”。但是，如果您这样做，我会将其放在网址的“用户”部分中。
例如：http://[电子邮件受保护]/myresource/myid
这样它也可以作为带有 basic-auth 的标头传递。
这取决于数据。
如果用户将提供数据，请将其放入网址中。
如果您提供数据，请将其放在标题中。