web-services - RESTful GET 和 POST 的不同模型

Question

在同一 URL 上使用不同的 GET/PUT/POST 模型是否违反了 REST 的思想或公认的约定？

一个例子:

考虑在 api/things 上找到的一个简单资源

我可以通过以下方式创建事物:

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/东西/500

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

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

创建时不能指定 Id 或 IsActive 设置。由服务器生成的 Id 始终以 Active 启动。

您无法更新 Id，因此无法更新使用它的“链接”，因此 PUT 模型不包含 Id 字段。

对此的一个强烈批评:我不能通过 POST 来创建一个新的，更改 Name 字段，然后将其放回 Update it。我必须知道删除 Id 和 links 字段。我可以“在我接受的内容上保持自由”并允许 Id 和 Links 出现在 PUT 请求中，但随后我需要做出额外的决定，例如“如果他们发送的 Id/Link 不同，是否为 400？，以及“如果他们不发送 Id/Link 是 400 吗？”。如果 API 声称接受 PUT 上的这些字段，则可以将其视为可以更新的契约(Contract)。

Answer 1

为不同的方法接受不同的 DTO 是完全有效的。通常，POST 会创建一个具有默认属性(例如 Id、StartDate 或 Active 等)的新实体，因此这些属性不会出现在“POST DTO”中。我倾向于回避 PUT，因为定义是您将一个实体替换为另一个实体，其中可能包含一个 Id。在您接受增量和部分对象的大多数情况下，我选择 PATCH。您可以验证发送的每个属性并确定它是否为只读属性。在某些情况下，根据角色，它可能对一个用户是只读的，而可由另一个用户修补。遵循这一点，POST 是一个 DTO，PATCH 是部分的，PUT 不存在，而 GET 返回完整的 DTO。

我只看到了几个 PUT 有用的地方。你想改变一个文件的二进制文件或者你有一个想要改变的集合，PUT 很棒。否则，我喜欢 PATCH。