分层 REST API 与规范化 REST API

Question

首先，我想解释一下我所创造的Hierarchical REST API和的含义。Normalized REST API

• 分层 REST API
  • 请求URL：可以使用具有多种类型内容的层次结构。（例如http://www.example.com/customers/12345/orders）
  • 响应体：可以包含所有请求的内容，没有任何遗漏，包括其他相关数据类型（例如acustomer包含an order）
    • 例如http://www.example.com/customers/12345

{
  "name": "John Doe",
  "orders": [{
      "id": 1,
      "price": 10,
      "delivered": true
    }, {
      "id": 2,
      "price": 11,
      "delivered": false
    }
  ]
}

• 标准化 REST API
  • 请求 URL：禁止使用 URL 的层次结构。
    • 不好
      • http://www.example.com/customers/12345/orders
      • http://www.example.com/customers/12345/orders/1
      • http://www.example.com/customers/12345/orders?accepted=true
    • 好的
      • http://www.example.com/customers
      • http://www.example.com/customers?firstName=John
      • http://www.example.com/customers/12345
      • http://www.example.com/orders/1
  • 响应正文：包含所请求内容类型的所有内容。如果有其他类型相关，则只返回该类型的ID。
    • 例如http://www.example.com/customers/12345

{
  "name": "John Doe",
  "orderIds": [1, 2]
}

我认为这两种方法都有各自的优点和缺点

• 分层 REST API
  • 优点
    • 可以在单个请求中获取所有必需类型的内容（例如来自的客户、订单、地址http://www.example.com/customers/12345）
  • 缺点
    • 如果数据层次很深，响应可能会呈指数级巨大且缓慢
    • 可能会发生循环引用
    • 数据重复（例如，两者的结果http://www.example.com/customers/12345可以http://www.example.com/stores/1包含相同的order数据）
• 标准化 REST API
  • 优点
    • 更快的响应（负载小，没有或很少有数据源连接，业务逻辑更少）
    • 通过标准化没有数据重复
  • 缺点
    • 如果您需要多种类型的内容，则需要多个请求（例如，要从orders某个特定的内容中检索所有内容customer，至少需要客户端发出 2 个请求）

我的问题是：

• Hierarchical REST API和有术语Normalized REST API吗？
• 哪一种更符合 REST API 指南？我也愿意接受其他选择。

Answer 1

是否有分层 REST API 和规范化 REST API 的术语？

不。

哪一种更符合 REST API 指南？

他们俩都“很好”。

考虑一下万维网，以及我们如何向浏览器传递 CSS 指令。我们可以将 CSS 直接嵌入到 HTML 页面中吗？是的。我们可以链接到通过不同资源获取的 CSS 吗？是的。

这两种方法都“符合 REST API 指南”。是的 - 更准确地说，它们之所以有效，是因为 HTML 是一种通用的标准化媒体类型，具有有关 CSS 引用如何工作的规则；每个人都以同样的方式理解这些规则。