Question

假设我想创建一个非常简单的todolist RESTful API，其中每个用户拥有一个待办事项列表。用户已通过http BASIC或DIGEST进行身份验证。

此时我不确定URL方案应该是什么样子。它会是：

http://servername/todos/

我的服务器根据http标头给我的身份验证来过滤相应的待办事项。

或者我应该在URI中包含用户名：

http://servername/users/username/todos/

在某些网站上，我甚至看到他们将用户名作为参数移交：

http://servername/todos?username=babsi

据我所知，所有三个选择都是无状态的，因为我总是收到用户名，但只是在不同的来源。从我所知道的，以确保正确的用户访问URI我总是需要检查http标头。那么你会考虑哪种方式在REST中进行最佳的URI设计，或者我应该以完全不同的方式做什么呢？

Answer 1

当您收到URL中的用户名与身份验证不匹配的请求时，URL中的用户名取决于您要执行的操作（如果有的话）。如果你想在这种情况下重新授权用户，那么是 - 可以在URL中输入用户名，否则如果没有这样的需要，可以将它放在你的标题或其他认证方案中。

有效要求的一个相当常见的例子是，如果您必须拥有可以冒充其他用户的主要用户（或此类用户组）。

Answer 2

您可以使用以下内容：

http://servername/todos/ GET list all todos
http://servername/users/ GET list all users
http://servername/users/{user_id}/ GET list an user
http://servername/users/{user_id}/todos/ GET list all todos for an user

我认为这里的重点是如何设计资源之间的关系，如果todo只是存在于用户的上下文中，则使用类似于上述方法的层次结构。作为一般规则，我通常遵循这个：

使用路径变量编码层次结构：/ parent / child

在路径变量中添加标点字符，以避免将层次结构隐含在哪里不存在：/ parent / child1; child2

使用查询变量来暗示算法的输入例如：/ search？q = jellyfish＆amp; start = 20

Answer 3

当有问题的用户始终是持有身份验证令牌的用户时，请在您的路径中使用诸如“我”之类的内容。

http://example.com/users/me/<path-to-inner-resource>

否则，应该像对待系统中的任何其他资源一样对待用户，在这种情况下，该用户的资源标识符将成为路径的一部分。

http://example.com/users/<id>/<path-to-inner-resource>

以 Twitter API 为例。 https://developer.twitter.com/en/docs/twitter-api/users/follows/quick-start/follows-lookup

REST URI设计用于属于特定用户的资源

3 个答案: