2

我想知道人们在多大程度上保持他们的应用程序 RESTful。在我看来，事情非常容易崩溃，此时我必须按照一位资深程序员曾经告诉我的那样，当我刚进入职业生涯并让他对他进行所有的哲学架构研究时：“只需编写该死的代码。”

具体示例，我在 Rails 应用程序中实现自定义身份验证，并且我有一个标准的“密码提醒”表单。从 REST 的角度来看，我们在流程结束时要做的是对用户对象进行 PUT，因为我们正在更新用户对象。但即使忽略您可能想要更新用户的多种方式（参见如何进行 REST-ful 更新？），我们一开始并不知道我们要更新的用户，到最后我们要更新发送电子邮件确认并使用用户标识符 + 安全密钥点击返回链接。所以现在最终触发用户更新的是一个简单的链接（哦，太可怕了！）——否则我必须用另一个按钮来惹恼我的用户，以实现 RESTful。

这只是引发我的问题的示例之一，但在我看来，在任何不平凡的应用程序中都必然会有几十个这样的案例。

那么，人们是否会使用 RESTful 架构作为一般指南，而巧妙的程序员会根据需要忽略？我从文献中得到的印象与此完全不同——因此问题是你如何处理例外情况。谢谢。

（实际上在我看来，这种情况下的最终结果将是另一种带有新密码/确认的表单，其目标可能是 PUT，但我通常认为这有时很笨重的感觉仍然存在。也许那是我的自己的缓慢——不会是第一次）。

4

2 回答 2

1

在我工作的地方，我们决定尽可能地使用 RESTful，但我们也将变得务实，当某些事情不符合 REST 准则时（并且所有相关人员都同意这是这种情况），那么我们愿意发散。话虽如此，我认为您可以使大多数用例有点 RESTful。

如果您不知道用户的 ID，这样的事情怎么样。以 id 作为电子邮件地址的更改密码令牌集合：

GET /changepasswordtoken/{userEmail}

或者，如果 API 的客户端知道用户 ID，这可能会更好：

GET /user/{userId}/changepasswordtoken

您要求GET更改用户的密码令牌。如果这是一个面向公众的 API，那么显然您不会在响应负载中返回它，但负载可能会返回一条消息，说“更改密码已发送到电子邮件”或其他内容。

然后使用更改密码令牌作为查询字符串参数来更新密码PUT或用户。PATCH

PUT /user/{userId}?changepasswordtoken=xyz

{
     "password": "new password"
}
于 2012-08-29T20:43:36.290 回答
0

来自http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_4：

REST 提供了一组架构约束，当作为一个整体应用时，它们强调组件交互的可扩展性、接口的通用性、组件的独立部署和中间组件，以减少交互延迟、加强安全性并封装遗留系统。

如果您需要一种强调混淆参与者和资源、点对点一次性交互以及全心全意拥抱和公开遗留系统（如 HTML 电子邮件）的架构风格，那么不，您不需要 RESTful . 寻找（或发明）符合您标准的建筑风格。REST 没有什么神奇之处。它是一组恰好适用于许多问题领域的约束，因为它是为满足他们的需求而设计的。如果您有不同的需求，应用相同的约束将适得其反并且是愚蠢的。

于 2012-08-30T12:06:57.033 回答