不同型号的RESTful GET和POST [英] Different Models for RESTful GET and POST
问题描述
这是否违反REST的想法，或者接受的惯例，在同一网址对GET / PUT / POST不同型号？
Does it violate the ideas of REST, or accepted conventions, to have different models for GET/PUT/POST at the same URL?
一个例子：
考虑在API /事发现了一个简单的资源
Consider a simple resource found at api/things
我可以创建一件事：
POST api/things
with body = { Name: "New Thing" }
这将返回我的事与位置沿
This returns me a thing along with location
{ Id: 500, Name: "New Thing", Links: ["api/things/500"] }
Location Header: api/things/500
我能得到的东西有：
I can get the thing with:
GET api/things/500
和我将获得
{ Id: 500, Name: "New Thing", Links: ["api/things/500"] }
如果我想更新它：
PUT API /事/ 500
If I want to update it: PUT api/things/500
{ Name: "Updated Thing", IsActive: false }
有在这个例子中是隐藏不同的模型背后的规则。
There are "rules" in this example that are hidden behind the different models.
- 当创建您不能指定ID或IsActive设置。正在生成的ID服务器总是开始为活动的。
- 您不能更新的ID，并由此链接，它使用它，所以PUT模型不包含一个ID字段。
这方面的一个强烈批评：我不能做一个POST来创建一个新的，更改名称字段，并把它放回去进行更新。我必须知道去除标识和链接领域。我可以在我接受自由主义，让IDS和链接要对PUT请求，但后来我需要像其他决定，它是一个400，如果他们发送ID / Link是不同的？和它是一个400，如果他们不发送ID /链接？如果API声称接受PUT这些领域，这可以被看作是一个合同，他们能够被更新。
One strong criticism of this: I cannot do a POST to create a new one, change the Name field, and PUT it back to Update it. I would have to know to remove the Id and links fields. I could "be liberal in what I accept" and allow the Ids and Links to be on the PUT request, but then I need to make additional decisions like, "is it a 400 if the Id/Link they send is different?, and "is it a 400 if they don't send an Id/Link?". If the API claims to accept those fields on PUT, that could be seen as a contract that they are able to be updated.
推荐答案
这是完全有效的，接受不同的DTO对不同的方法。很多时候，一个POST将创建一个拥有默认属性，如编号，起始日期或活动等新的实体，那么这些属性都没有一个POST DTOpresent。我倾向于回避PUT的客场，因为定义是你与另一个，这可能包括ID替换一个实体。我选择在你接受三角洲和局部对象大多数情况下补丁。您可以验证被送到了每个属性，并确定它是否是一个只读属性或没有。在某些情况下，基于角色，它可以是只读为一个用户，和跳接由另一个。按照此，POST一个DTO，补丁是局部的，PUT是不存在的，和GET返回完整的DTO。
It is perfectly valid to accept different DTO's for different methods. Quite often, a POST will create a new entity with default properties such as Id, StartDate or Active, etc. so these properties are not present on a "POST DTO". I tend to shy away from PUT's since the definition is you are replacing one entity with another, which could include an Id. I opt for PATCH in most cases where you are accepting deltas and partial objects. You can verify each property that was sent up and determine if it's a readonly property or not. In some cases, based on roles, it may be readonly for one user, and patchable by another. By following this, POST is one DTO, PATCH is partial, PUT is non-existent, and GET returns the full DTO.
我只看到一对夫妇的地方，PUT是非常有用的。要更改一个文件的二进制或您有想改变一个集合，PUT是伟大的。否则，我爱的补丁。
I've only seen a couple places where PUT is useful. You want to change the binary of a file or you have a collection that you want to change, PUT is great. Otherwise, I love PATCH.
这篇关于不同型号的RESTful GET和POST的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
