Question

这是一个多部分的问题：

如果REST API的URL包含自然数作为路径段，那么这个数字通常会被解释为索引或键的行为吗？
对深层资源路径执行 PUT 时，通常会将路径解释为状态声明吗？这意味着要创建路径中所有不存在的资源。或者，如果路径中的任何资源不存在，是否应该返回错误？
扩展问题2，如果路径确实存在，并且路径定义了与现有资源结构不同的资源结构，是否应覆盖预先存在的资源，再次作为状态声明，或者是否应返回错误指示类型不匹配？

例如，考虑端点：

domain.tld/datasource/foo/2/bar/1/baz

foo是一个字符串，用于标识顶级资源。
2可以解释为索引或键。
bar是一个字符串，被解释为键。
1可以解释为索引或键。
baz是一个字符串，解释为键，指向叶节点。

换句话说，位于domain.tld/datasource标识符foo下的数据可以是以下任何一种：

基于索引：

[
  null,
  null,
  {
    'bar': [
      null,
      {'baz': null}
    ]
  }
]

基于密钥：

{
  '2': {
    'bar': {
      '1': {
        {'baz': null}
      }
    }
  }
}

基于索引和键：

{
  '2': {
    'bar': [
      null,
      {'baz': null}
    ]
  }
}

问题1

2和1应该被视为整数还是字符串？由于这可能无法知道，REST URL中是否有类型注释的标准来解决这种情况？到目前为止，白板上的一些解决方案如下，其中2是一个关键，而1是一个索引：

domain.tld/datasource/foo/2:str/bar/1:int/baz
- 其中:str表示前面的值是键
- 和:int表示前面的值是索引
domain.tld/datasource/foo/2/bar/1/baz?types=ki
- 其中k是types的成员0，映射到第一个类似int的段，并指示该值是键
- 和i，作为types的成员1，映射到第二个类似int的段，并指示该值是索引

问题2

如果上述数据都不存在，那么针对此路径的 PUT 是否会创建这些资源或返回错误？如果返回错误，是否应该单独创建每个级别的每个资源，在路径上需要多个 PUT ？

问题3

如果第一个插图（基于索引）中的数据已经存在，那么来自第二个插图（基于键）的数据是否会强制覆盖路径中所有级别的所有数据，或者返回指示类型不匹配的错误？这里的推断是，任何更改类型的赋值都需要多个 PUT 。

我可能过于复杂化了问题或遗漏了一些基本的东西，但我没有找到明确的指导方式。我可以完全控制系统，并可以执行我认为合适的任何规则。但是，我对这种体验很感兴趣，这意味着交互应该易于推理，逻辑，预期，确定性等。

Answer 1

从我的角度来看，在尝试'宁静'或'休息'时，你永远不应该做出像“深度资源”这样的东西 - 我真的没有看到好处。它只是使系统更难理解，使用和开发（例如：看你的问题:)）。

为什么不保持简单并为单个资源设置“单个”网址？这样，客户很清楚PUT会做什么，DELETE会做什么。

所以，举个例子，您可以拥有列表资源端点domain.com/datasource，它将返回已注册的所有foos的列表。它会返回一个HREF列表...比如domain.com/foo/1 ...在某些元数据下面，foo / 1也可能包含一个条形列表....但同样，它们没有嵌套在'foo中URI'，它们是简单的顶级资源，例如'domain.com/bar/1'。

这样客户端就可以轻松删除，更新，创建项目。您可以链接它们，在实体中设置正确的链接。

关于你的问题2和3：我认为完全取决于你的系统。如果你看到链接domain.com/datasource/foo/1/bar/2/baz作为一个大资源，意味着响应将不仅包括有关baz的信息，还包括bar，foo和datasource的信息，是的，put a will'重新创建'（完全更新）资源。如果该链接“仅”返回有关baz的信息，则put只会完全更新此资源。

REST URL：整数与字符串以及PUT的行为

1 个答案: