Rest 正确的方法是什么？

我可以在/user/{username}URL上获取用户的数据，并且响应为

{
  "id" : 1,
  "username" : "testuser",
  "email" : "test@example.org"
}

在我的实现中，如果将数据放在/user/{username}URL上，后端将使用指定的用户名创建或更新用户

当后端在URL（如/user/foo）和http负载（如）中获得用户名时，处理这种情况的正确方法是什么：

{
  "id" : 1,
  "username" : "bar",
  "email" : "test@example.org"
}

我应该返回409-冲突还是应该使用有效负载中的用户名创建或更新用户？

在最初的概念中，URL应该是URI-资源标识符，也就是说，唯一地标识系统中的用户实体

因此，如果在您的模型中用户名是唯一的，并且不可能有两个同名的用户，那么您可以在资源标识符URL中使用用户名。 示例-/user/foo

但是，如果有可能两个id不同的用户可以拥有相同的用户名，那么根据严格的REST，您不能将用户名用作URL的一部分——它不再是REST，而是一些在PUT请求的有效负载中接受JSON的web服务

长话短说：

1如果用户名不是系统中用户的唯一标识符-不要在URL中使用它，而是使用id，例如，您提到的URL将是/user/1

2如果用户名是系统中的唯一标识符，那么您可以使用/user/foo

============================================================================ 在这两种情况下，您都需要进行完整性检查，确保有效负载中的值与URL中的值相对应： 对于1，检查URL中的id是否与有效负载中的id相同 对于2，检查URL中的用户名是否与有效负载中的用户名相同

在不一致的情况下，我将返回状态HTTP 422 Unprocessable Entity-请求格式正确，但由于语义错误而无法遵循。

---

它准确地描述了语义不一致性——JSON有效负载的结构是正确的，但URL和有效负载中的语义id或用户名不匹配。

这个问题是一个意见问题，所以这里是我的问题。您不应允许通过两个不同的操作执行相同的操作。我设计这种方法的方式是实现PUT on/user以创建新用户，并在/user/{username}上进行补丁以进行更新。无论是在URL还是HTTP负载中，请求都不应包含重复的参数。