我目前正在尝试使用ASP.NET Web API，EF5代码优先方法创建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.)更新过程大致相同。好的做法是只放入整个对象，然后让服务器尝试自己进行更新？
目前，我已经使用上述工具链实现了这种“基本”方案。但是解决方案已经感觉相当复杂。尤其是手动摆弄和设置许多对许多关联会使事情变得比我想象的要复杂。
现在，当涉及到并发处理时，我真的不相信在断开连接的情况下所有这些事情都容易处理，因为一切都来自客户端，服务器需要找出所有问题。
那么从API的角度来看，这种(简单的)方案的“正确”实现是什么？拆分实体创建/更新是否更容易？但是然后我会问自己如何绑定不同的请求，以便服务器现在可以将2个或更多请求属于1个创建/更新。
希望有人能读到这一点，并能遵循我的想法。
最佳答案
我想您会发现阅读POST与PUT很有帮助，因为两者都可以用来“创建”和“更新”。您要支持哪个。这个答案应该有帮助:
PUT vs POST in REST
简而言之，将PUT定义为幂等的，无论将1次或100次PUT都保证结果相同。不应使用PUT进行部分更新。将您的PUT视为将添加(如果该ID处的资源尚不存在)或替换(如果确实存在)的东西可能会更有用。 POST在其功能上是“使者”。它可以以各种方式使用。
关于您的问题:
1)如果我理解正确，则您要发布一个包含其关联标签数组的发布对象(可能是新标签也可能不是新标签)。没关系;您只需要在服务器上具有一些逻辑即可确定是否需要添加任何这些标签。如果需要，可以要求它是现有标签ID的数组，但是我认为这会使API难以使用。此类行为基于您的需求和客户的需求。我认为在大多数情况下，第一步会更好...但是您仍然可以提供添加标签并在以后分配标签的选项。
2)是的，将整个对象放置为一个好习惯。至于包含尚不存在的标签的对象(需要添加标签)，除非包含要创建的标签的ID，否则我不确定这是否“正确”。即使它不是“正确”的，只要您不允许创建重复的标签(这会违反幂等性)，您仍然可以选择执行此操作。也许其他人可以对此进行权衡。
关于rest - ASP.NET Web API设计的最佳实践？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16990965/