我很难理解如何在JSON API中呈现相互依赖的资源。
考虑一下，我们有一个资源Collection，它可以拥有一个名为List的多个资源。没有List的{{1}}没有意义，所以我会说Collection没有List就无法生存。此外，Collection有多个名为List的资源，还需要Item才能存在。
分配是固定的。例如，您无法将List移动到其他List或Collection移动到其他Item。您只能向/从现有List添加/删除Lists或从现有Collection添加/删除Items。
List的端点只是Collection。 /api/collection将返回特定的Collection。
由于api/collection/{id}与Collection有关系，因此根据JSON API规范List存在关系related link，该规范仅代表连接到的/api/collection/{id}/lists资源List资源，其中包含在URL中指定的ID。
但最好的是制作api的其余部分？
我执行端点Collection和/api/lists以链接到api/lists/{id}资源。资源List也是如此。 Item和/api/items。
这种方法的好处在于我可以像/api/items/{id}和related link一样“干净”关系api/lists/{id}/items。
糟糕的是，我不知道在api/lists/{id}/collection和/api/lists上返回什么，因为如果没有父元素，它们就不会真正存在。我应该返回错误代码403还是只返回所有列表和项目？两者都很难看。
发布新资源可以在/api/items和/api/items上使用。但在第一种情况下，您必须将关系包含在POST正文中的api/lists/{id}/items资源中，因为您无法通过URL确定它。
对于List我提供了List和api/collection/{id}/lists等端点。对于api/collection/{id}/lists/{id}，我提供Item和api/collection/{id}/lists/{id}/items。
好消息是我清楚地映射了哪个资源属于哪个其他资源。
糟糕的是网址越来越长。
另一点是关系的api/collection/{id}/lists/{id}/items/{id}。例如，我想从related links链接到Item。该网址为：List。
（更糟糕的是关系的api/collection/{id}/lists/{id}/items/{id}/list：self link。但我不认为这会有问题，因为api/collection/{id}/lists/{id}/items/{id}/relationships/list链接是可选的。我也是认为我不需要关系的self链接，因为正如我在分配修复之前所说的那样。您无法将self分配给另一个List或指定{{1}到第二个Collection。所以我不需要改变关系之间的联系，因此我不需要Item这样做。）
格式化List的另一个选项是self link。但这与资源related link {id}的链接相同。这对JSON API规范有效吗？由于分配是固定的，这是有道理的，但是，这也感觉有点难看。