我有一个基于 REST 的服务，用户可以在其中返回他们自己的书籍列表（这是一个私人列表）。
网址目前为../api/users/{userId}/books
每次调用时，他们还将提供之前提供的身份验证令牌。
我的问题是：
在 URL 中提供 userId 是多余的吗？当我们在每次调用中获得一个令牌时，我们可以找出哪个用户正在执行调用并返回他们的书籍列表。 userId 不是严格要求的。
删除 userId 是否会破坏 REST 原则，因为 /users/books/ 看起来应该为所有用户返回所有书籍？
我是否应该硬着头皮对令牌进行身份验证，然后检查令牌是否属于同一个userId？
【问题讨论】：
标签： rest restful-authentication
您可以在 URL 中使用me 来指代当前用户。使用这种方法，您将拥有如下 URL：/users/me/books。
在 URL 中提供
userId是多余的吗？当我们在每次调用中获得一个令牌时，我们可以找出哪个用户正在执行调用并返回他们的书籍列表。userId不是必需的。
您可以考虑这样做：/users/me/books。其中me 指的是当前用户。比/users/books更容易理解，可以用来退回用户的所有书籍。
为了一些灵活性，除了/users/me/books，你可以支持/users/{userId}/books。
URL /users/me 可用于从当前用户返回数据。许多API，例如StackExchange、Facebook、Spotify和Google+都采用这种方法。
删除
userId是否会破坏 REST 原则，因为/users/books/看起来应该为所有用户返回所有书籍？
我认为它不会违反任何 REST 原则，但我认为您的资源不会被正确地识别。正如我上面回答的那样，我会使用/users/me/books 并支持/users/{userId}/books。
我是否应该硬着头皮对令牌进行身份验证，然后检查令牌是否属于同一个
userId？
当使用 URL 中的 userId 向用户请求私人信息时，检查令牌是否属于 URL 中包含 userId 的用户是没有害处的。
【讨论】：
/me 的外观，如果其他大型API 也遵循相同的原则，我很乐意使用它。非常感谢！
/users/me?id=ID_CONNECTED_USER 并匹配令牌和 ID，我的路线是唯一的，我可以缓存它。
REST 是面向资源的，所以在您看来，资源用户或书籍是什么。我的观点是书。我认为你可以请求这些资源 /api/books?user={userid} 但是此 URL 无法解决您的权限问题，因此您必须在代码中使用可以通过 OAuth2 协议或其他任何方式获得的令牌信息来执行此操作。
【讨论】：
我不认为删除 userId 会破坏任何 REST 原则，因为毕竟 /users 和他们 /books 对解释有点开放，而 REST 基本上对此一无所知，另一方面，如果你打算保留请求中的 id，您必须检查用户 id 是否与连接的用户相同，无论如何，对我来说 1 是多余的，因为您已经拥有该信息，另外，每次您要进行无用的检查时，因为无论如何，经过身份验证的 userId 在所有情况下都是您要信任的。
最好的问候
【讨论】：