使用不完全表示的PUT方法

Question

{'id': 1,
 'username': 'joedoe',
 'email': '[e-mail]',
 'password_hash': '9039dmk38f84uf4029i339kf32f0932i',
 'last_visit': '2013-11-04 21:09:01',
 'public': true,
 '_links': {'self': {'href': 'http://foo.bar.com/api/users/1'}}

}

PUT /api/users/1

{'username': 'joeydoey',
 'email': '[e-mail]'}

1和2都是有效的，因为没有标准化的行为，由媒体类型决定如何处理它。这感觉不对，因为PUT不是从属于资源本身，而是替换资源。

请记住，我不是在问什么是正确的，什么是有意义的。我在问哪一个是标准支持的。

Answer 1

只要PUT的结果完全替代了客户机对资源的理解（即，那些未传递的属性的先前值不会影响PUT之后的值），它就应该成功。然而，这确实让它看起来有点困惑，因为许多人倾向于将PUT与字段级更新语义（而不是完全替换）混淆起来。

虽然这里从技术上讲没有违反REST约束，但传递所有值而不求助于服务器默认值可能是一个更好的主意，因为这将有助于保持向前兼容性。默认值会随着时间的推移而变化，因此通常应该避免。

但是，您的链接示例并不是指不传递默认值，因此它不是“不完整表示”的好示例。相反，链接不是客户端对服务器的资源表示的一部分。我认为您在这里引入了另一个概念：只从服务器返回给客户机的属性。这就是我在引发这篇文章的另一个帖子上所说的。

因此，让我用Accept和Content-Type头来装饰您的示例，以说明我的观点。

请求

PUT /api/users/1 HTTP/1.1
Content-Type: application/vnd.example.api.client+json

{'username': 'joeydoey',
 'email': '[e-mail]'}

回应

200 OK
Content-Type: application/hal+json;profile=application/vnd.example.api.server

{'id': 1,
 'username': 'joeydoey',
 'email': '[e-mail]',
 'password_hash': '9039dmk38f84uf4029i339kf32f0932i',
 '_links': {'self': {'href': 'http://foo.bar.com/api/users/1'}}
}