我应该在URL方案中包含经过身份验证的用户吗

Question

给定具有登录用户的Web服务以及每个用户的资源。 URL方案是否应包含用户ID，或者HTTP请求与用户的关联是否应通过cookie或其他方式完成。 E.g。

1. lock网址
中包含的所有信息 必须从session / cookie / header 获取
2. GET acme.com/{user-ID}/books/{book-ID}用户ID

   我喜欢1.（完全指定的网址），如

   1. 每个资源都有一个网址
   2. 它允许授权模仿，例如适当授权的支持用户在必要时访问用户记录。
   3. 完全自我描述，URL可以通过电子邮件发送，加入书签等

   我还可以看到它在安全方面存在问题 - 所有用户ID都是可猜测的。因此，需要一个经过适当测试的授权方案。

   什么是最佳做法？我错过了什么吗？

Answer 1

取决于您的使用案例。拥有用户标识的一个非常好的副作用是它使具有共享缓存的共享客户端上的http缓存更容易。有一个http varys标头，但是当你将身份验证作为cookie传递时，这种方法效果不佳。它可以使URL的共享变得更加困难，因为用户拥有的任何url仅适用于它们。您可以使用重定向概念对此进行补充，以便如果用户使用其他人的用户ID获取URL，则服务器可以重定向/提供请求用户的资源版本（可能）。

如果允许匿名访问，路径中的用户ID可能会变得有点麻烦/笨重。

最重要的是要记住（因为你将其标记为休息）是客户端应该永远不必拥有用户id的句柄，而不是它是某个obtuse URL的一部分。该服务应始终提供URL以及为用户填写的用户ID，这样客户无需担心必须填写用户ID，并且随着您的应用程序成熟并且您决定是否拥有用户ID客户仍在运作，这是一个错误。

Answer 2

您列出的首选acme.com/{user-ID}/books的原因都是有效的，应该足以让您选择该网址架构。

如果可能，我会在Authorization标头中保留实际经过身份验证的用户信息。通常在REST中，我发现从长远来看，它需要遵循底层（HTTP）协议的约定。

是的，您需要一种方法来确定授权用户可以访问属于网址用户的图书。