如何设计URL以从REST API中返回当前用户的数据？

Question

我有一个基于REST的服务，用户可以返回自己的书籍列表（这是一个私人列表）。

网址目前为../api/users/{userId}/books

每次通话时，他们也会提供先前提供的身份验证令牌。

我的问题是：

1. 提供网址中的userId是多余的？当我们通过每个呼叫获得令牌时，我们可以找出正在执行呼叫的用户并返回他们的书籍列表。 userId并非严格要求。

2. 将userId暂停REST原则移除为/users/books/会是否应该为所有用户返回所有图书？

3. 我是否只需咬住子弹并根据令牌对其进行身份验证，然后检查该令牌是否属于同一个userId？

Answer 1

简短回答

您可以在网址中使用me来引用当前用户。使用此方法，您将拥有以下URL：/users/me/books。

每个问题的答案

  

提供网址中的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的用户是没有害处的。

Answer 2

我不认为删除userId会破坏任何REST原则，因为毕竟，/ users和他们/ books，它有点开放的解释和REST基本上没有任何关于它的说法，另一方面如果你要去留在请求中的id，你必须检查用户ID是否与连接用户相同，不管怎样，对我来说1是多余的，因为你已经有了这些信息，而且，每次你要做无用的检查，因为无论如何，authentified userId是你在所有情况下都会信任的。

最好的问候

Answer 3

REST是面向资源的，因此在您的观点中，资源用户或书籍是什么。我的观点是它的书。我认为你可以申请这些资源 / API /书？用户= {}的userid 但是这个URL无法解决您的权限问题，因此您必须在代码中使用OAuth2协议或其他任何方式获取令牌信息。