0

我们收到了创建 REST api 的请求。我对我们客户提供的示例感到有些困惑。正如您在下面看到的，他们已经在@ 之前的 URL 中识别了 app_id 和 secret。URI 的其余部分看起来像我所期望的。

这是有效的吗？我想这可能是我以前从未见过的一些奇怪的 cURL 格式。

https://{application_id}:{api_secret}@api.example.com/entity/{entity_id}/ 
https://{application_id}:{api_secret}@api.example.com/entity/{entity_id}/entity_locations/{locations_id}/

只是看看是否有人以前见过这种格式？

4

1 回答 1

1

URI 由多个部分组成，其中一个是权限部分，可以包含可选username:password元素。

完整的方案是：

scheme://username:password@domain:port/path?query_string#fragment_id

这样，您的 REST api 将保持无状态[不依赖于以前的应用程序状态，例如在会话中存储内容]。但我建议您不要明确地使用该username:password@stuff路由，而是依赖Basic HTTP Auth，因此至少以 Base64 编码发送凭据。

编辑：现在您要询问有关 BasicAuth 的简短说明-事情是这样的：

  • 您提出请求http://johndoe:12345@service/api/foo/bar；
  • 凭证好吗？好的，您会得到200 OK适当的响应；
  • 他们不是吗？你得到401 Unauthorized回应。

在后一种情况下，浏览器[或执行请求的任何其他程序/脚本] 应该通过登录弹出窗口提示用户。

通常浏览器会要求您缓存凭据而不是每次都询问它们，但这并不意味着它们不会被发送 - 只是对受保护资源的每个请求都带有这样的标头：

Authorization Basic base64encode(username:password)

您对字符串base64encode进行编码的自定义方式在哪里。username:password

于 2012-08-26T15:59:09.103 回答