Json RESTURL：整数vs字符串和PUT的行为

这是一个多部分的问题：

给定一个RESTAPI，其URL包含自然数作为路径段，通常预期的行为是将该数解释为索引还是键

对深度资源路径执行PUT时，通常预期的行为是将路径解释为状态声明吗？这意味着将创建路径上所有不存在的资源。或者，如果路径上不存在任何资源，是否应返回错误

展开问题2，如果路径确实存在，并且路径定义的资源结构不同于现有的资源结构，那么是否应该覆盖先前存在的资源（再次作为状态声明），或者是否应该返回一个指示类型不匹配的错误

例如，考虑端点：

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

• foo

  是一个字符串，用于标识顶级资源

• 2

  可以解释为索引或键

• bar

  是一个字符串，被解释为键

• 1

  可以解释为索引或键

• baz

  是一个字符串，解释为键，指向叶节点

换句话说，驻留在标识符

foo

下的

domain.tld/datasource

中的数据可以是以下任意一种：

基于索引的：

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

基于密钥的：

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

{
  '2': {
    '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

    ，作为

    类型的成员0，映射到第一个类似int的段，并指示该值是一个键

  • 和

    i

    ，作为

    类型的成员1，映射到第二个类似int的段，并指示该值是索引

问题2

如果上述数据均不存在，则是否应将放在此路径上创建这些资源或返回错误？如果返回错误，是否应单独创建每个级别的每个资源，并要求对路径放置多个PUTs

问题3

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

---

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

从我的角度来看，在尝试“restful”或“resty”时，你永远不应该做“深层资源”之类的事情——我真的看不到好处。这只会使系统更难理解、使用和开发（例如：查看您的问题：）

为什么不保持简单，为单个资源提供“单一”URL？这样，客户就可以清楚地知道PUT将做什么，DELETE将做什么

因此，作为一个示例，您可以使用列表资源端点domain.com/datasource，它将返回所有已注册的foo的列表。它将返回一个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将“重新创建”（完全更新）资源。如果该链接“only”返回有关baz的信息，那么put只能完全更新此资源。

关于最后两个问题，我认为这取决于RESTful API的级别。例如，查看，在对资源执行PUT之前，您必须实际导航到该资源，因此您可以假设该路径是有效的。同时，硬编码URL而不是导航并不是使用此类API的正确方式。