我试图围绕解决基于REST的API中的概念的最佳方式.不包含其他资源的平面资源没有问题.我遇到麻烦的地方是复杂的资源.
例如,我有一本漫画书的资源.ComicBook上有如各种属性author,issue number,date,等.
漫画书也有一份1..n封面清单.这些封面是复杂的对象.它们包含大量关于封面的信息:艺术家,日期,甚至是封面的64位编码图像.
对于GET上ComicBook我可以回相声,和所有的封面,包括他们的base64'ed图像.获得一部漫画可能不是什么大不了的事.但是假设我正在构建一个客户端应用程序,希望在表格中列出系统中的所有漫画.
该表将包含ComicBook资源中的一些属性,但我们当然不希望显示表中的所有封面.返回1000本漫画书,每本漫画书都有多个封面,这将导致大量数据流过网络,在这种情况下,最终用户不需要这些数据.
我的直觉是制作Cover资源并ComicBook包含封面.所以现在Cover是一个URI.GET漫画书现在可以使用,而不是Cover我们为每个封面发回一个URI 的巨大资源,客户可以根据需要检索封面资源.
现在我在创建新漫画方面遇到了问题.当我创建一个时,我肯定想要创建至少一个封面Comic,事实上这可能是一个商业规则.
所以现在我卡住了,我要么强制客户端通过先提交给执行业务规则Cover,获得URI为盖,然后POST荷兰国际集团一个ComicBook与URI列表,或者我POST就ComicBook需要在寻找不同的资源比它吐出出.传入的资源是POST和GET深拷贝,其中传出的GETs包含对依赖资源的引用.
Cover在任何情况下,资源可能都是必要的,因为我确信作为客户,我想在某些情况下解决覆盖方向问题.因此,无论依赖资源的大小如何,问题都以一般形式存在.一般来说,如何处理复杂的资源而不强迫客户只是"知道"这些资源是如何组成的？
假设我有一个资源，Person而我有一个嵌套的资源SomeResource。在以下场景中应该返回哪个状态代码以及为什么？
/Person/1/SomeResource (SomeResource does not exist)
/Person/1/SomeResource (Person does not exist)
我认为 404 应该在两种情况下都使用，但不是每个人都同意，我想知道为什么。您可能会争辩说，这Person是基础资源，SomeResource只是该资源的“属性”，SomeResource因此在第一种情况下应该不返回任何内容，但在第二种情况下返回 404的请求。我认为这可能是一种选择，但我仍然更喜欢 404。我完全不喜欢的另一种情况是返回 500 并带有错误描述，这也是我在讨论中听到的另一种选择，但这迫使消费者针对我不喜欢的异常进行编程。500 对我来说意味着出了点问题，你真的无能为力。
问题是，争论是你不知道为什么你得到了 404，如果你得到了它，是因为Person不存在还是因为SomeResource不存在。
更新 1：
也许我应该突破SomeResource到一个单独的资源，如
/SomeResource/1
它返回类似 的响应{data: {the data}, person: {person data}}，如果两者都丢失，则仅返回 404，但如果数据丢失，则返回 200 并带有空数据。
更新 2：
我想我想出了要使用哪个状态代码，当这个人不存在时它是 400，因为我当时认为它是一个你不应该做的请求，也就是说，一个错误的请求。当SomeResource缺少时，我会选择 404，因为Person确实存在但缺少嵌套资源。