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