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

Question

我正在尝试使用ASP.NET Web API和EF5 Code First方法创建一个类似REST的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个创建/更新。

希望有人能读到这里，并能理解我的混乱思路。

- devployment

Answer 1

我认为你会发现阅读有关POST vs PUT的文章很有帮助，因为两者都可以用于“创建”和“更新”。由你决定要支持哪些。这个答案应该会有所帮助： PUT vs POST in REST

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

关于你的问题：

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

2) 是的，PUT整个对象是一个很好的做法。 就包含尚不存在的标签的对象而言（这将需要添加它们），我不确定这是否“正确”，除非包括要创建的标记的ID。 即使不“正确”，只要不允许创建重复标签（这将违反幂等性），您也可以选择执行此操作。 或许其他人可以发表自己的看法。

- MysteriousWhisper