Question

我有两个具有严格父/子层次关系的资源，其中子节点没有父节点，并且子节点ID必须是父资源中从1开始的单调递增整数，因此不是唯一的全球资源集。让我们称他们为Foo和Bar，其中Foo是父母：

Foo: ABC
  |- Bar: 1
  |- Bar: 2
  |- Bar: 3
Foo: QWE
  |- Bar: 1
  |- Bar: 2

在数据库中，我们将其存储在一个带有简单复合自然键的表中：

Foo | Bar | Value
===================
ABC | 1   | shizzle
ABC | 2   | bizzle
ABC | 3   | fizzle
QWE | 1   | lorem
QWE | 2   | ipsum

标准要求类型/ ID组合在api中必须是唯一的，以允许包含的资源正确链接到，因此要创建一个唯一的条形码ID，我们必须加入复合键，如Foo_Bar，即ABC_1和QWE_1。丑陋并且在客户端需要了解密钥组合和加入char的一些问题，但是公平，我们总是可以将自然密钥添加为数据或元，以供客户端使用。

我的问题是儿童资源的网址。为了与文档ID保持内部一致性，URL可能如下所示：

https://example.com/api/v1/foos/ABC/bars/ABC_1

但这似乎是多余的重复＆＃39; ABC＆＃39;，更不用说丑陋了，与我们的主网站网址不一致。我更喜欢使用：

https://example.com/api/v1/foos/ABC/bars/1

我认为我可以自由地做我想做的事，但我怀疑如果他们假设它们是相同的话，这可能会导致某些库出现问题？通常，URL是否需要与内部资源类型/ ID具有任何逻辑关系？

与此相关，资源ID可以使用＆＃39;。＆＃39;加入复合键而不是＆＃39; _＆＃39;？这将使它与关系路径保持一致，所以＆＃39; foos.bars＆＃39; =＆＃39; ABC.1＆＃39;。虽然该标准禁止＆＃39;。在成员名称中，ID名称似乎没有这样的约束？

干杯！

约翰。

Answer 1

规范在格式url上不是绝对的。认为它建议网址匹配资源的ID 来自http://jsonapi.org/recommendations/#urls-individual-resources

将资源集合视为由资源ID键入的集合。可以通过将资源的ID附加到集合URL来形成单个资源的URL。   例如，ID为＆＃34; 1＆＃34;将有URL：

/照片/ 1

在此之后，您访问ID为ABC_1的foo资源的URL将是 https://example.com/api/v1/foos/ABC_1

并相应地获取id为1的条形码资源 https://example.com/api/v1/bars/1

关于您的示例网址https://example.com/api/v1/foos/ABC/bars/ABC_1，虽然无效，但您在规范中找不到类似于resource_type / resource_id / relation_name / relation_id（具有4个嵌套级别）的任何类似示例。

规范建议有3个级别，在您的情况下将返回一个资源标识符对象数组：
resource_type / resource_id / relation_name

建议通过将/ relationships /和关系名称附加到资源的URL来形成关系URL。

例如，照片的评论关系将包含以下网址：

/照片/ 1 /关系/评论