我正在尝试基于现有数据库模型构建 REST API。我已经构建了一个，但在开始编写客户端应用程序之前，我想让它更简单明了。我决定使用 ASP.NET Core 作为后端技术和 WPF 前端（还有 Angular/Ionic 前端）。数据库模型非常简单，它包含大约 30 个表（具有相关资源和集合的不同文档）。
到目前为止，API 使用平面 URL - 这样有时我必须将子对象与其父对象一起发布/放置。我应该使用嵌套 URL (API/Document/{id}/Item) 以使发送对象更简单，或者甚至使用使该对象扁平化的唯一 id？
当我需要来自子对象的数据以获取数据网格源所需的数据时，我遇到的第二个问题 - 我应该添加新方法/控制器以获取具有数据网格所需的所有属性的 ViewModel，还是应该先获取父对象集合然后再获取在客户端应用中获取子对象并构造视图？
【问题讨论】：
标签： c# rest api collections
最终，此选择取决于许多参数以及您的团队偏好。您没有提供足够的细节来给出绝对的建议，但即使您确实给出了建议，也可能没有任何绝对的答案。
如果您对这两个问题有疑问，我建议选择扁平、简单、完整的数据传输对象。 （编辑：如果你有链接的集合当然不会是平的，但它仍然是简单而完整的）
这样做的好处是减少了对 API 的连接/调用次数，这对所有网络基础架构以及客户端都有一定的开销。
其次，我认为这可以简化开发（但我承认这是值得商榷的）
此外，关于第二个问题，它有助于分离您的 API 和客户端应用程序之间的关注点。构建 ViewModel 通常是必要的（出于安全或性能原因，您可能不想公开某些信息），但不要仅仅为了客户端应用程序而使其过于复杂；您希望以后的新客户端/新版本可以轻松使用您的 API。
向您展示为什么打很多个人电话通常会更糟糕：
想象一下，如果您想检索 40 个文档。
如果每个文档都有 Item1 和 Item2，那么如果您必须检索 Documents/1/Item1、Documents/1/Item2 等，则调用次数将增加 80 次。！
此外，对于您的前端开发，您必须管理回调（首先调用文档，一旦完成获取 item1 和 item2），这似乎比一次性获取所有内容更复杂（因为最终您需要等待一切就绪）。
更糟糕的是，在调用之间，可能某些对象发生了变化，他的孩子也发生了变化。您可能以父对象的版本 A 结束，但以它的子项的版本 B 结束！
当然，有些情况可能会使分解的子项调用变得有趣。
如果您经常只需要获取文档的项目部分，而不需要重新加载整个文档，那将是一个很好的理由。
或者如果整个文档很大，并且您希望能够在完整加载完成之前显示部分加载的文档。
我可以看到的最后一个缺点是，当您链接相关对象的集合时，您可以有很多重复的链接对象。在这种情况下，如果您需要避免过多的重复，并且只对主对象、关系和加载相关对象进行几次单独调用，即使某些对象被多次使用，那么做一些更棘手的事情可能是有意义的。
【讨论】：