5

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

在这一点上，我不确定 URL 方案应该是什么样子。可不可能是：

http://servername/todos/

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

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

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

在某些网站上，我什至看到他们将用户名作为参数传递，如下所示：

http://servername/todos?username=babsi

据我所知，所有三个选项都是无状态的，因为我总是收到用户名，但只是来自不同的来源。据我所知，为了确保正确的用户可以访问 URI，无论如何我总是需要检查 http 标头。那么，您认为哪种方式是 REST 中最好的 URI 设计，或者我应该完全采用不同的方式？

4

3 回答 3

2

在 URL 中包含用户名取决于您在收到 URL 中的用户名与身份验证不匹配的请求时想要做什么（如果有的话）。如果您想在这种情况下重新授权用户，那么可以 - 在 URL 中包含用户名是可以的，否则如果不需要，可以将其仅包含在您的标头或其他身份验证方案中。

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

于 2013-05-29T15:11:33.747 回答
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

我认为这里的重点是你想如何设计你的资源之间的关系，如果一个待办事项可以存在于用户的上下文中，使用像上面的层次结构这样的方法。作为一般规则，我通常遵循以下规则：

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

将标点字符放在路径变量中以避免暗示不存在的层次结构：/parent/child1;child2

使用查询变量来暗示算法的输入，例如：/search?q=jellyfish&start=20

于 2013-05-29T15:18:36.497 回答
0

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

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

于 2021-02-27T16:37:08.877 回答