REST GET 请求、动词和 apikey
我想创建一个灵活的 API Rest 服务器。我将允许客户端使用 HTTP 或 APIKEY 进行身份验证。
我的问题是：将 apikey 添加到 GET 请求的正确方法是什么？我的问题是 apikey 污染了 url。
我想象这样的事情：/book/1/apikey/s4cr4t！
I want to create a flexible API Rest server. I will allow the clients to authenticate using HTTP or an APIKEY.
My question is: what is the correct way to add the apikey to a GET request? My problem is the apikey pollutes the url.
I imagine something like this : /book/1/apikey/s4cr4t !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，您应该只使用授权标头。这就是它的用途。
将其放入 URL 中是一个坏主意，因为：
a) 正如您所说，它会污染 URL
b) 如果您决定使用 SSL 来确保安全，那么 API 仍会出现在日志文件中
c) 缓存最终会创建相同表示的多个副本，每个 api 密钥对应一个副本。
有关创建您自己的授权方案的更多信息，请访问此处< /a>.
In my opinion you should only use the Authorization header. That's what it is there for.
Putting it in the URL is a bad idea because:
a) as you said it pollutes the URL
b) if you decide to go SSL for security then the API will still appear in log files
c) caches will end up creating multiple copies of the same representation, one for each api key.
For more information on creating your own Authorization scheme go here.
可以使用
Authorization标头传递凭证：Credentials may be passed using the
Authorizationheader:这完全取决于您想要走多远，但机制保持不变：
上下文
目标是通过某种程度的安全性来识别客户端。 （注：安全性是另一个详细讨论）。请记住，REST 的“功能”是无状态的：这意味着服务器上除了资源之外没有会话状态。为了保持客户端无状态，它需要为每个请求提供足够的信息以确保该请求是独立的。它必须为服务器提供一种识别客户端的方法，例如用户名/密码、API 密钥或令牌。
您有多种选项可以执行此操作，因此这里有一些：
添加 HTTP 标头以识别客户端
这里可以使用授权标头并将其与每个请求一起发送。有多种身份验证方案，但请坚持使用标准方案，例如基本身份验证。在这里您可能会坚持使用 SSL。如果您愿意，身份验证过程会生成一种令牌。
您还可以使用 cookie。 Cookie 必须不包含任何信息，除非它是指向服务器上有状态会话资源的“指针或密钥”（注意：会话是“其余合法”的资源）。您可以通过执行响应为 200 OK 的 PUT (+info) 或响应为 201 Created 且位置为：/sessions/123334 的 POST (+info) 来创建此资源。然后服务器可以验证会话，例如超时、有效的客户端 IP 地址、API 密钥等。
通过上述方法，您还可以定义客户标头，例如 Api-Key: XXXX。但随后你就将自己限制在特殊客户上。 Set-Cookie 是“众所周知的”标头，因此浏览器将以透明的方式处理它们。然后可以通过以下链接并填写表单（PUT + POST）进行身份验证（创建会话资源）来完成身份验证过程。
在内容中对标识符进行编码
在这里您也可以自由地做您想做的事情。只需向您的内容添加一个字段/令牌/ID 并让服务器验证它。
RESTful API 通过解析链接来执行应用程序流。另请参阅 HATEOAS 和 菲尔丁的话。当您有单独的登录应用程序过程时，这也适用。
不要对 URI 中的任何数据进行编码。 （带外信息）
It all depends on how far you want to go but the mechanics stays the same:
Context
The goal is to identify the client with some level of security. (Note: Security is another detailed discussion). Remember that one if the “features” of REST is to be stateless: That means no session state on the server except for resources. To keep the client stateless, it needs to supply on each request enough information that the request is independent. It must give the server a way to identify the client such as a username/password, API Key or token.
You have various options to do this so here are some:
Add HTTP headers to identify the client
Here one can use the Authorization header and send it with each request. There are various authentication schemes but stick to the standard ones such as Basic Auth. Here you would probably stick to SSL. The authentication process generates a kind of token if you like.
You can also make use of a cookie. The cookie must contain no information except that it is a “pointer or key” to a stateful session resource on your server (note: session it a resource which is “rest-legal”). You can create this resource by doing a PUT (+info) with response 200 OK or POST (+info) with a response of 201 Created and Location: /sessions/123334. The session can then be validated by the server such as timeout, valid client ip address, api key etc.
With the method above, you can also define a customer header such as Api-Key: XXXX. But then you limit yourself to special client. Set-Cookie are “well known” headers so browser will handle them kind of transparently. The authentication process can then be done by following links and filling in forms (PUT + POST) to authenticate (create session resource).
Encode an identifier in the content
Here you are free to do what you want too. Just add a field/token/id to your content and let the server verify it.
A RESTful API does application flow by resolving links. See also HATEOAS and Fielding's words. This also applies when you have a separate process of logging in to the application.
Do not encode any data in the URIs. (Out of band information)