分层 REST API 与规范化 REST API
Hierarchical REST API vs Normalized REST API
首先,我想解释一下我编的Hierarchical REST API
和Normalized REST API
的含义。
- 分层 REST API
- 请求URL:可以使用层次结构,内容类型多。 (例如
http://www.example.com/customers/12345/orders
)
- Response body:可以包含所有请求的内容,没有任何遗漏,包括其他相关数据类型(例如
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
- 响应正文:包含所请求内容类型的所有内容。如果其他类型相关,则只有 return 个 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 指南?我也愿意接受其他选择。
Is there terminology for the Hierarchical REST API and Normalized REST API?
没有
Which one is more fit to the REST API guideline?
他们都“很好”。
想想万维网,以及我们如何向浏览器传送 CSS 指令。我们可以将 CSS 直接嵌入到 HTML 页面中吗?是的。我们可以通过不同的资源获取 link 到 CSS 吗?是的
这两种方法都“符合 REST API 准则”。是的 - 更准确地说,它们起作用是因为 HTML 是一种通用的标准化媒体类型,具有关于如何引用 CSS 的规则;每个人都以同样的方式理解这些规则。
首先,我想解释一下我编的Hierarchical REST API
和Normalized REST API
的含义。
- 分层 REST API
- 请求URL:可以使用层次结构,内容类型多。 (例如
http://www.example.com/customers/12345/orders
) - Response body:可以包含所有请求的内容,没有任何遗漏,包括其他相关数据类型(例如
customer
包含order
)- 例如
http://www.example.com/customers/12345
- 例如
- 请求URL:可以使用层次结构,内容类型多。 (例如
{
"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
- 不行
- 响应正文:包含所请求内容类型的所有内容。如果其他类型相关,则只有 return 个 ID。
- 例如
http://www.example.com/customers/12345
- 例如
- 请求URL:禁止来自URL的分层结构。
{
"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 指南?我也愿意接受其他选择。
Is there terminology for the Hierarchical REST API and Normalized REST API?
没有
Which one is more fit to the REST API guideline?
他们都“很好”。
想想万维网,以及我们如何向浏览器传送 CSS 指令。我们可以将 CSS 直接嵌入到 HTML 页面中吗?是的。我们可以通过不同的资源获取 link 到 CSS 吗?是的
这两种方法都“符合 REST API 准则”。是的 - 更准确地说,它们起作用是因为 HTML 是一种通用的标准化媒体类型,具有关于如何引用 CSS 的规则;每个人都以同样的方式理解这些规则。