我目前正在尝试使用ASP.NET Web API，EF5 Code First方法创建REST'ish Web服务后端。现在寻找一些建议，以避免可能是最知名的新手错误。
对于多种情况，如下所示，为控制器结构建模的最佳方法是什么。
假设我们的博文中包含与之关联的标签。博客帖子可以包含许多标签，并且可以将标签分配给许多博客帖子。博客帖子和标签都属于客户。我会说很标准。但我首先要关注的是如何通过以下（标准？）端点设计更新博客文章。
GET - /api/posts/{id} => Load the post by id
DELETE - /api/posts/{id} => Delete the post by id
POST - /api/posts/ => Create a new post from the JSON in the body
PUT - /api/posts/{id} => Update the post from the JSON in the body. Tags as well
1。）将标签简单地发布到数组[{"name":"tag1"}, {"name":"tag2"}]中并让服务器查明标签是新的还是已经存在的客户并且只需将其分配给创建博客文章。
分两步（首先创建帖子，然后创建/分配任务）在断开连接的网络世界中感觉不对。
2。）更新过程或多或少都是一样的。将PUT放在整个对象并让服务器尝试自行更新是不错的做法？
目前，我使用上述工具链实现了这个“基本”方案。但解决方案已经感觉相当复杂。特别是手工摆弄和设置多对多关联会使事情变得比我想象的更复杂。
当涉及到并发处理时，我并不确信在断开连接的场景中，当一切都从客户端发出并且服务器需要找到所有内容时，所有这一切都很容易处理。
那么从API的角度看这个（简单？）场景的“正确”实现是什么？拆分实体创建/更新可能更容易吗？但后来我会问自己如何绑定不同的请求，以便服务器现在可以有2个或更多请求属于1个创建/更新。
希望有人读到这一点，并且可以跟随我的毛茸茸的想法。
答案 0 :(得分：0)
我认为你会发现阅读POST与PUT很有帮助，因为两者都可以用来“创建”和“更新”。这取决于你想要支持哪些。这个答案应该有帮助： PUT vs POST in REST
简而言之，PUT被定义为幂等，保证无论你输入1次还是100次，结果都是相同的。不应使用PUT进行部分更新。将您的PUT视为将添加的内容（如果该id上的资源尚不存在）或替换（如果存在）可能更有用。 POST的功能“杂乱无章”;它可以以各种方式使用。
关于你的问题：
1）如果我理解正确，你要求POST一个包含其相关标签数组的帖子对象（可能是也可能不是新的）。没关系;你只需要在服务器上有一些逻辑来确定它是否需要添加任何这些标签。如果你想要，你可以要求它是现有标签的ID数组，但我认为这会使API比它需要的更难使用。这样的行为是基于您的需求和客户的需求。我认为在大多数情况下，一步会更好......但是你仍然可以选择添加标签并在以后分配它们。
2）是的，将整个物体投入是一种好习惯。至于包含尚不存在的标签的对象（需要添加它们），我不太确定这将是“正确的”，除非包含要创建的标签的ID。即使它不是“正确的”，只要你不允许创建重复的标签（这会违反幂等性），你仍然可以选择这样做。也许其他人可以权衡这一点。