ASP.NET Web API 设计的最佳实践？

Question

我目前正在尝试使用 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 个创建/更新。

希望有人能读到这一点，并能追随我的胡思乱想。

Answer 1

我认为阅读 POST 与 PUT 对您有所帮助，因为两者都可用于“创建”和“更新”。由您决定要支持哪些。这个答案应该有帮助： PUT vs POST in REST

简而言之，PUT 被定义为幂等的，保证无论你 PUT 1 次还是 100 次，结果都是一样的。不应使用 PUT 进行部分更新。将您的 PUT 视为将添加（如果该 id 处的资源尚不存在）或替换（如果存在）的东西可能更有用。 POST 的功能“混乱”；它可以以各种方式使用。

关于您的问题：

1) 如果我理解正确，您要求发布一个包含其关联标签数组的帖子对象（可能是新标签，也可能不是新标签）。没关系;您只需要在服务器上有一些逻辑来确定它是否需要添加任何这些标签。如果你愿意，你可以要求它是现有标签的 ID 数组，但我认为这会使 API 比它需要的更难使用。此类行为基于您的需求和客户的需求。我认为在大多数情况下，一步会更好......但您仍然可以提供添加标签并稍后分配它们的选项。

2) 是的，PUT 整个对象是个好习惯。至于包含尚不存在的标签的对象（这将需要添加它们），我不确定这是否“正确”，除非包含要创建的标签的 ID。即使它不是“正确的”，您也可以选择这样做，只要您不允许创建重复的标签（这将违反幂等性）。也许其他人可以对此进行权衡。