RESTful GET和POST的不同模型

Question

在同一个URL下，使用不同的模型进行GET/PUT/POST操作是否违反了REST的理念或公认的约定？

举个例子：

考虑一个简单的资源，位于api/things下。

我可以通过以下方式创建一个thing：

POST api/things 
with body = { Name: "New Thing" }

这会返回一个东西和它的位置

{ Id: 500, Name: "New Thing", Links: ["api/things/500"] }
Location Header: api/things/500

我可以通过以下方式获取该物品：

GET api/things/500

而我将获得

{ Id: 500, Name: "New Thing", Links: ["api/things/500"] }

如果我想要更新它：

PUT api/things/500

{ Name: "Updated Thing", IsActive: false }

在这个例子中，不同的模型背后隐藏着“规则”。

1. 创建时无法指定Id或IsActive设置。 Id始终由服务器生成，并始终处于活动状态。
2. 您不能更新Id或使用它的“链接”，因此PUT模型不包含Id字段。

对此有一个强烈的批评：我不能使用POST创建新的，更改Name字段并将其PUT回更新。我必须知道删除Id和links字段。我可以“在接受内容方面保持开放”，允许Id和Links出现在PUT请求中，但那么我需要做出其他决策，例如，“如果他们发送的Id/Link不同，则是否返回400？”，以及“如果他们没有发送Id/Link，则是否为400？”如果API声称接受PUT上的这些字段，那么可以将其视为能够被更新的合同。

- Drew

Answer 1

接受不同的DTO（数据传输对象）用于不同的方法是完全有效的。往往，POST将创建一个具有默认属性（例如Id、StartDate或Active等）的新实体，因此这些属性在“POST DTO”中不存在。我倾向于避开PUT，因为其定义是用另一个实体替换一个实体，其中可能包括一个ID。在大多数情况下，我选择使用PATCH来接受增量和部分对象。您可以验证发送的每个属性并确定它是否为只读属性。在某些情况下，根据角色，它对某个用户是只读的，并且对其他用户可进行修补。按照此方式，POST是一个DTO，PATCH是部分内容，PUT不存在，而GET返回完整的DTO。

我只看到过几个使用PUT的场合。如果您想更改文件的二进制文件或者您想更改集合，那么PUT非常好用。否则，我喜欢使用PATCH。

- ManOVision

---

这似乎支持一种信念，即我提出问题背后的问题是不适当地使用PUT而不是PATCH：http://restful-api-design.readthedocs.org/en/latest/methods.html - Drew

那个链接似乎是一个相当不错的资源。我得把它全部读完。看起来PATCH方法会适合你解决这个特定的问题。 - ManOVision