分层 REST API 与规范化 REST API

Question

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

• 分层 REST API
  • 请求 URL：可以使用具有多种内容类型的层次结构。 （例如http://www.example.com/customers/12345/orders）
  • 响应正文：可以包含所有请求的内容，没有任何遗漏，包括其他相关数据类型（例如，customer 包含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
  • 优点
    • 响应速度更快（负载小，数据源没有或很少连接，业务逻辑更少）
    • 通过规范化没有数据重复
  • 缺点
    • 如果您需要多种类型的内容，则需要多个请求（例如，要从某个 customer 检索所有 orders，至少需要来自客户端的 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 引用如何工作的规则；每个人都以同样的方式理解这些规则。