【问题标题】:REST service call which starts a workflow?启动工作流的 REST 服务调用?
【发布时间】:2013-11-07 18:11:33
【问题描述】:

我们正在构建 Web 服务并尝试遵循 REST 准则。该服务允许用户创建和修改他们的帐户以及随之而来的个人资料(想想电子邮件首选项、地址等)。

在大多数情况下,我认为我们已经把事情搞得很清楚了,但是有一个用例我不确定是否合适。

假设我们有一个调用 /password ,用户可以在其中 PUT 一个包含他们当前和所需密码的请求。这很好,但我们正在尝试找出一个适当的调用来启动忘记密码工作流,这会在服务器上启动一些操作,并且用户会收到有关如何继续的电子邮件的说明。

由于资源应该是名词而不是动词,因此在 URL 的某处添加 /forgotpassword 没有意义。我们一直在考虑的一种方法是使用与更改密码相同的 PUT,但使用不同的 Content-Type / Accept 标头来区分所需的结果。我对此没意见,但我想知道其他一些选项可能是什么。

【问题讨论】:

  • 你的问题的标题几乎是矛盾的。使用 RPC 构建 REST 服务就像用正方形构建一个圆圈。并非不可能,但确实适得其反。
  • @PedroWerneck 我不是要使用 RPC 构建一个 REST 服务,我要问的是如何在仍然遵循 RESET 的同时完成在这种情况下确实是必须启动的操作或工作流的事情原则。
  • 当然,我意识到了这一点,这就是为什么我是下面答案的作者,但你应该考虑编辑标题,因为它不能清楚地反映你的要求。跨度>
  • @PedroWerneck 变了,你觉得现在更好了吗?
  • 好多了。 :) 毫无疑问。

标签: rest


【解决方案1】:

如果您正在寻找一个名词,“密码恢复”链接关系可以用作用户下的恢复请求集合吗? POST 可以启动工作流程:

请求

POST /users/1/recovery-request
Content-Type: application/json

{
  email: "foo@bar.com",
  hint_question: 1,
  hint_answer: "MyMother'sMaidenName"
}

回应

204 No Content

这样做的好处是有人能够轻松地查询恢复集合以查看您重置密码的频率。

【讨论】:

    【解决方案2】:

    最直接的方法是假设对您的/password 的删除请求是重置密码的请求。它应该返回 202 Accepted 响应,并且 GET 应该向它发出信号,直到密码重置工作流程完成或超时。

    用户不应执行包含当前密码和所需密码的 PUT 请求,除非 /password 表示返回他们当前和以前的密码。 PUT 是一个完整的替代品。如果该密码是用户用来对您的服务进行身份验证的密码,那么您应该期待一个 Authorization 标头。如果不是,那么您不应该使用 PUT 并将其设为 POST。

    【讨论】:

    • 使用 DELETE 似乎很奇怪。在我们的例子中,现有密码不会失效,用户永远不必完成工作流程。如果更改密码不应该包含当前密码,您如何合理确保帐户所有者是更改密码的人?在几乎所有情况下,我都看到用户必须输入他们当前的密码才能被允许更改它,即使他们刚刚在 2 秒前登录。
    • 这就是为什么您应该像往常一样返回 202 Accepted,而不是 200 OK 或 204 No Content。您可以通过 Authorization 标头对其进行身份验证来确保帐户的所有者是执行操作的人。如果这不可能,并且这些用户与 API 的用户不同,那么您应该将其设为 POST,将信息提交给负责重置操作的资源。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-07-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多