gpt4 book ai didi

rest - ASP.NET Web API 设计的最佳实践?

转载 作者:行者123 更新时间:2023-12-01 06:18:50 24 4
gpt4 key购买 nike

我目前正在尝试使用 ASP.NET Web API、EF5 Code First 方法创建一个 REST'ish Web 服务后端。现在寻找一些建议来避免可能是最知名的新手错误。

为如下多对多场景建模 Controller 结构的最佳方法是什么。

假设我们有一些带有相关标签的博文。一篇博文可以有多个标签,一个标签可以分配给多篇博文。博客文章和标签均属于客户。我会说非常标准。但我首先关心的是如何通过以下(标准?)端点设计来更新博客文章。

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 的角度来看,这个(简单?)场景的“正确”实现是什么?拆分实体创建/更新可能更容易吗?但随后我会问自己如何绑定(bind)不同的请求,以便服务器现在可以将 2 个或更多请求属于 1 个创建/更新。

希望有人读到这里,并能理解我的毛茸茸的想法。

最佳答案

我认为您会发现阅读有关 POST 与 PUT 的内容很有帮助,因为两者都可用于“创建”和“更新”。这取决于你想要支持哪些。这个答案应该有帮助: PUT vs POST in REST

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

关于您的问题:

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

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

关于rest - ASP.NET Web API 设计的最佳实践?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16990965/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com