PHP REST API 逻辑

Question

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

阅读Beginner's Guide to HTML and REST，其中指出：

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

1 /clients/add

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

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

如下：

www.example.com/users [get] www.example.com/users/1 [get] www.example.com/users/1 [put] www.example.com/user/1 [delete] www.example.com/user [post]

这会用完 4 个常用动词来发出请求。

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

编辑：

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

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

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

www.example.com/users [get] www.example.com/users/1 [get] www.example.com/users/1 [put] www.example.com/user/1 [delete] www.example.com/user [post]

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

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

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

Answer 1

有些动作很难以真正的 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

请参阅this question 了解如何检索用户权限。这个问题的重点是您通常需要多种方式来访问您的资源。有些是基于 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] 带有参数用户 ID 和密码。

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

www.example.com/session/sessionID

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

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

Answer 2

如果我需要登录或登录等功能怎么办？ 一般任何其他类型的动作命令？ url应该怎么写 在这种情况下，路由器应该如何重定向？

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

/login-form

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

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

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

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

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

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

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

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

希望对你有帮助:)

Answer 3

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

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

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

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