将 API 密钥放在标头或 URL 中
我正在为我公司的数据设计一个公共 API。我们希望应用程序开发人员注册 API 密钥，以便我们可以监控使用和过度使用。
由于 API 是 REST，我最初的想法是将此密钥放在自定义标头中。我看到谷歌、亚马逊和雅虎就是这样做的。另一方面，我的老板认为，如果密钥只是 URL 的一部分等，那么 API 会更容易使用。 "http://api.domain.tld/longapikey1234/resource”。我想对此有一些话要说，但它违反了 URL 的原则，即您想要什么的简单地址，而不是您想要它的方式或原因。
您认为将密钥放在 URL 中合乎逻辑吗？或者，如果将简单的 javascript 前端写入某些数据，您是否不想手动设置 HTTP 标头？
I'm designing a public API to my company's data. We want application developers to sign up for an API key so that we can monitor use and overuse.
Since the API is REST, my initial thought is to put this key in a custom header. This is how I've seen Google, Amazon, and Yahoo do it. My boss, on the other hand, thinks the API is easier to use if the key becomes merely a part of the URL, etc. "http://api.domain.tld/longapikey1234/resource". I guess there is something to be said for that, but it violates the principle of the URL as a simple address of what you want, and not how or why you want it.
Would you find it logical to put the key in the URL? Or would you rather not have to manually set HTTP headers if writing a simple javascript frontend to some data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
它应该放在 HTTP 授权标头中。规范在这里 https://www.rfc-editor.org/rfc/rfc7235
It should be put in the HTTP Authorization header. The spec is here https://www.rfc-editor.org/rfc/rfc7235
如果你想要一个可能吸引老板的论点：想想 URL 是什么。 URL 是公开的。人们复制并粘贴它们。他们分享它们，把它们放在广告上。没有什么可以阻止某人（有意或无意）将该 URL 邮寄给其他人使用。如果您的 API 密钥位于该 URL 中，那么每个人都拥有它。
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 密钥，而不是在 URL 中。
如果从浏览器尝试，URL 会保存在浏览器的历史记录中。这是非常罕见的情况。但是当后端服务器记录所有 URL 时就会出现问题。它可能会暴露 API 密钥。
您可以通过两种方式在标头
基本授权：
中使用 API 密钥来自 stripe 的示例：
curl 使用 -u 标志来传递基本身份验证凭据（在 API 密钥后添加冒号将阻止它询问您以获得密码）。
自定义标头
It is better to use API Key in header, not in URL.
URLs are saved in browser's history if it is tried from browser. It is very rare scenario. But problem comes when the backend server logs all URLs. It might expose the API key.
In two ways, you can use API Key in header
Basic Authorization:
Example from stripe:
curl uses the -u flag to pass basic auth credentials (adding a colon after your API key will prevent it from asking you for a password).
Custom Header
在参数中传递 api 密钥会使客户端很难保守其 API 密钥的秘密，他们往往会定期泄漏密钥。
更好的方法是将其传递到请求 url 的标头中。您可以在代码中设置 user-key 标头。
为了测试您的请求 Url，您可以通过将 user-key 标头设置为您的 api-key 来使用 google chrome 中的 Postman 应用程序。
passing api key in parameters makes it difficult for clients to keep their APIkeys secret, they tend to leak keys on a regular basis.
A better approach is to pass it in header of request url.you can set user-key header in your code .
For testing your request Url you can use Postman app in google chrome by setting user-key header to your api-key.
我不会将密钥放在 url 中，因为它确实违反了 REST 这个松散的“标准”。但是，如果您这样做，我会将其放在网址的“用户”部分中。
例如： http://[电子邮件受保护] /myresource/myid
这样它也可以作为带有 basic-auth 的标头传递。
I would not put the key in the url, as it does violate this loose 'standard' that is REST. However, if you did, I would place it in the 'user' portion of the url.
eg: http://[email protected]/myresource/myid
This way it can also be passed as headers with basic-auth.
这取决于数据。
如果用户提供数据，请将其放入 URL 中。
如果您提供数据，请将其放入标题中。
It depends on the data.
If the user provides the data, put it in the URL.
If you provide the data, put it in the header.