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

简短的回答

你可以使用 me 在URL中引用 当前用户 。使用此方法,您将获得如下URL: /users/me/books .

每个问题的答案

正在为 userId 在URL中是否冗余?当我们在每次调用中获得一个令牌时,我们可以找出哪个用户正在执行调用,并返回他们的图书列表。这个 用户ID 并非严格要求。

你可以考虑这样做: /用户/我/书籍 哪里 我 指的是 当前用户 。这比 /users/books ,可用于从用户处返回所有书籍。

为了一些灵活性 /用户/我/书籍 ,您可以支持 /users/{userId}/books .

URL /users/me 可以用于从当前用户返回数据。许多API,如 StackExchange , Facebook , Spotify 和 Google+ 采用这种方法。

将删除 用户ID 打破REST原则 /users/books/ 看起来它应该为所有用户返回所有书籍?

我不认为这会违反任何REST原则,但我认为您的资源不会得到适当的补偿。正如我上面回答的,我会使用 /用户/我/书籍 以及支持 /用户/{userId}/books .

我是否应该咬紧牙关,根据令牌对他们进行身份验证,然后检查令牌是否属于同一个令牌 用户ID ?

当使用 用户ID 在向用户请求私人信息的URL中,使用 用户ID 包括在URL中。

我不认为删除userId会破坏任何REST原则,因为毕竟,/users和他们/books对解释有点开放,REST基本上对此一无所知,另一方面,如果你要保留请求中的id,你必须检查用户id是否与连接的用户相同,对我来说,1是多余的,因为你已经有了这些信息,而且,每次你都会进行无用的检查,因为无论如何,经过身份验证的userId是你在所有情况下都会信任的。

顺致敬意,

REST是面向资源的,所以在您看来,什么是资源用户或书籍。我的观点是书。我想你可以申请这些资源 /api/书籍?用户={userid} 但是这个URL不能解决您的权限问题,因此您必须在代码中使用OAuth2协议或其他任何协议可以获得的令牌信息来解决这个问题。