1
REST复杂/复合/嵌套资源[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 改善这个问题 我正在努力解决在基于REST的API中解决概念的最佳方法。不包含其他资源的固定资源没有问题。我遇到麻烦的地方是复杂的资源。 例如,我有一部漫画资源。ComicBook拥有所有喜欢各种各样它的属性author,issue number,date,等。 一本漫画书也有1..n封面清单。这些封面是复杂的对象。它们包含有关封面的许多信息:艺术家,日期,甚至是封面的base 64编码图像。 对于GET上,ComicBook我可以退回漫画,以及所有的封面,包括其base64版本的图像。获得一部漫画可能不是什么大事。但是,假设我正在构建一个客户端应用程序,该应用程序希望在表格中列出系统中的所有漫画。 该表将包含ComicBook资源中的一些属性,但是我们当然不想显示该表中的所有封面。归还1000本漫画书,每本漫画书都有多个封面,这将导致大量数据荒谬地通过网络传播,在这种情况下,最终用户不需要这些数据。 我的本能是制造Cover资源并ComicBook包含掩护。所以现在Cover是一个URI。GET现在在漫画书上工作时,Cover我们会为每个封面发送一个URI ,而不是大量的资源,客户可以根据需要检索Cover资源。 现在,我在创建新漫画时遇到了问题。当然Comic,在创建时,我肯定会想要创建至少一个封面,实际上这可能是一条业务规则。 所以现在我卡住了,我要么强制客户端通过先提交给执行业务规则Cover,获得URI为盖,然后POST荷兰国际集团一个ComicBook与URI列表,或者我POST对ComicBook发生在不同的资源寻找比它吐出出来。对于收到的资源POST和GET深拷贝,其中传出GET小号包含对相关资源的引用。 该Cover资源在任何情况下都可能是必需的,因为在某些情况下,我确定作为客户端我想解决的问题涵盖了方向。因此,无论依赖资源的大小如何,问题都以一般形式存在。通常,您如何处理复杂的资源而又不强迫客户端仅“知道”这些资源的组成方式?