0

我最近阅读了几个教程来介绍自己以了解更多有关其余 API 的信息。但是，我在这里和那里有一些疑问，希望有人可以帮助我解决这个问题。

阅读HTML 和 REST 初学者指南，其中指出：

“最好将资源视为名词。例如，以下内容不是 RESTful：

1 /clients/add

这是因为它使用 URL 来描述操作。这是区分 RESTful 和非 RESTful 系统的一个相当基本的点。 "

因此，我想知道在我拥有用户资源并访问它以执行通常的插入/更新/删除/检索的这种情况下

如下：

www.example.com/users [get] <-- 检索所有记录
www.example.com/users/1 [get] <-- 检索 id 为 1 的记录
www.example.com/users/1 [put ] <-- 更新 id 为 1 的记录
www.example.com/user/1 [delete] <-- 删除 id 为 1 的记录
www.example.com/user [post] <-- 插入一个新的用户记录

这将用完 4 个常用动词来提出请求。

如果我需要诸如登录之类的功能，或者通常可能需要任何其他类型的操作命令，该怎么办？在这种情况下应该如何形成 url 以及路由器应该如何重定向？

编辑：

在查看了各种评论和答案之后。我从他们那里得到的结论是，最终的解决方案将是“尽可能使用休息原则，并在不使用时使用带有函数的查询字符串方法”。

但是，我正在考虑实现的一个轻微变体（不再是一个宁静的实现，而是遵循类似的概念）并且想知道它是否可以这样工作。希望大家可以给我这方面的建议。

使用我需要实现的相同身份验证/登录功能，是否可以改为：

www.example.com/users [get] <-- 检索所有记录
www.example.com/users/1 [get] <-- 检索 id 为 1 的记录
www.example.com/users/1 [put ] <-- 更新 id 为 1 的记录
www.example.com/user/1 [delete] <-- 删除 id 为 1 的记录
www.example.com/user [post] <-- 插入一个新的用户记录

像往常一样，如果我需要执行某项操作，它将是这样的：

[controller]/[action] --- user/authenticate [post] --- 登录
[controller]/[id]/[action] --- user/1/authenticate [put] --- 注销

这行得通吗？我会面临任何可预见的问题吗？是否已经有类似的实现？请多多指教！

4

3 回答 3

1

REST 是无状态的，因此您需要将所有需要的信息放入所有查询中。这个想法是使用 HTTP 动词（GET、PUT、DELETE、POST - 正如您已经描述的那样）。

如果您想要 REST API 的用户身份验证，请使用 HTTP 基本身份验证或您自己的身份验证。您必须将每个请求的身份验证信息发送到服务器（无状态）。

如果您不想要 HTTP 基本身份验证，您可以尝试一些令牌身份验证或任何其他身份验证。

编辑：如果你想要一个“检查登录”资源，建立你自己的。例如带有 http 基本身份验证标头信息的 GET /account/checklogin。此请求的结果取决于您的身份验证信息。

于 2013-02-05T13:10:20.787 回答
0

有些动作很难以真正的 RESTful 方式建模 - 但登录，例如，可以使用以下伪代码实现：

GET the user rights whose userID is x and password is y
if (user rights found)
  assign rights to current user
else
  do not assign rights to user

有关如何检索用户权限的信息，请参阅此问题。这个问题的重点是您通常需要多种方式来访问您的资源。有些是基于 ID 或众所周知的属性，例如：

  • www.example.com/users/department [get]（获取一个部门的所有用户）
  • www.example.com/users/roleName [get]（获取特定角色的所有用户）
  • www.example.com/users/status/active [get]（获取所有“活跃”的用户）

但是，某些访问用户的方式（尤其是当您需要组合两个或更多过滤属性时）使用查询字符串参数更易于管理。例如：

www.example.com/users?department=xxx&role=yyy&status=active [获取]

因此，您的 REST API 可能会按照以下方式公开一个 URL：

www.example.com/users?userName=xxxx&password=yyy [获取]

此 URL 将根据用户数据库匹配用户名和密码参数，并返回 404（如果它们与已知用户不匹配）或代表用户的文档及其访问权限。

然后，您的客户端代码管理当前用户的会话 - 即将状态设置为“已登录”，并将会话与该用户配置文件相关联。

完成这项工作的关键是将责任分配给正确的层 - API 不应该管理用户会话，这是客户端应用程序的责任。在某些情况下，它的效果并不特别好——不过，不确定你的情况是否如此。

如果您真的想使用 POST 请求，当然可以将“登录”方法视为该用户会话的开始。因此，您可以执行以下操作：

www.example.com/session [POST] 带有参数 userID 和密码。

这将返回用户配置文件和权限的表示；它还可以创建可在 URL 下访问的文档

www.example.com/session/sessionID

www.example.com/session/user/ID/session

然而，一般来说，在 API 中管理会话状态是一个非常危险的想法 - 几乎总是，您希望客户端会话由与客户端交互的应用程序管理，而不是由它与之交谈的 API 管理。

于 2013-02-05T11:18:36.663 回答
0

如果我需要诸如登录之类的功能，或者通常可能需要任何其他类型的操作命令，该怎么办？在这种情况下应该如何形成 url 以及路由器应该如何重定向？

拥有 login- action资源不是 RESTful ，但提供 login-form 资源是RESTful：

/login-form

您在响应中返回的 HTML 表单作为code-on-demand；您正在提供一个已配置的软件来帮助用户提供他们的登录凭据。

将资源标识为 just 不会有任何问题/login- 我添加了表单部分以使示例清晰。

您应该避免在需要身份验证的情况下进行重定向，因为它会破坏 Web 浏览器以外的客户端的界面；相反，您可以：提供登录表单的链接；或实际在响应中提供登录表单代码。

如果您想管理身份验证，我更喜欢创建身份验证令牌的方法；对于 Web 浏览器，我认为为了帮助客户端为每个请求提供令牌而重载单个 cookie 是可以接受的，因为他们没有其他合理的方式来控制他们发送的 Auth 标头；显然，如果您正在编写自己的客户端应用程序，这不是问题。

在下面回答您的评论，auth-token 场景中登录表单的目的是创建一个新的身份验证令牌。因此，以 REST 的方式思考，您对 auth-token 的用户列表进行建模并发布 auth-token 的表示。此表示可能包含用户的用户名和密码。您可以让用户选择他们自己的令牌，或者您可以为他们选择它并在响应中返回它。不需要操作-URI，并且在成功创建新的 auth-token 后设置任何 cookie。

我建议学习 Amazon S3 REST API。它与您的要求略有不同，但它是我见过的对潜在 REST 身份验证系统的最佳深入描述：

http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html

您关于以 REST 方式管理用户的想法是准确的。

希望能帮助到你 ：）

于 2013-02-05T13:10:20.077 回答