在RESTful API中更改密码（使用PATCH时进行服务器验证）

Question

在RESTful API中，我有用户资源分别在/users和/users/:id上，包括他们的用户名、电子邮件地址和密码。

当我想要更新用户信息时，我可以轻松地使用一些JSONPatch数据来执行PATCH：/users/:id操作。

现在的问题是，我不知道如何处理包含currentPassword、newPassword和newPasswordConfirm表单的更改密码场景。

应该使用什么方法（PATCH似乎合适但存在问题），以及数据应该以何种方式传输（body/header/...）。

更广泛地说，应该如何处理具有进一步验证字段的补丁。

这个帖子看起来相关，但没有涉及这个确切的主题。

- Aides

Answer 1

如果你想部分更新一个用户资源，不妨考虑使用PUT来替换密码，而不是使用PATCH。

你可以使用/users/:id/password作为端点，其中password是用户资源的子资源。请求替换密码的示例如下：

PUT /users/1/password HTTP/1.1
Host: api.example.com
Content-Length: 113
Content-Type: application/json
Authorization: Basic YWRtaW46c2VjcmV0

{
    "currentPassword" : "secret",
    "newPassword": "othersecret",
    "newPasswordConfirm" : "othersecret"
}

- cassiomolin

---

我考虑过这个解决方案，但希望避免在 API 上暴露单个字段。除此之外，我更愿意使用 POST 方法，因为 PUT 操作的定义是幂等的，而这个操作显然不是。 - Aides

您能否看一下我的答案并提供反馈意见？ - Aides

Answer 2

在深入研究JSONPatch后，我能够想出一种将test操作添加到修补数据中的方法。

这可能看起来有些像：

[
    { "op": "test", "path": "/password", "value": "oldPassword" },
    { "op": "replace", "path": "/password", "value": "newPassword" },
    { "op": "test", "path": "/password", "value": "newPasswordConfirm" }
]

这种方法有什么问题吗？

- Aides

---

我认为这种方法可以很好地解决问题。但是，在我看来，“PUT”方法更清晰明了。 - cassiomolin

好的，可能会成为决定性因素的一件事是我必须确保消费者实际上使用这个请求格式。如果没有进一步的服务器端验证，消费者可以只发送替换而不是测试用例。 - Aides