时间戳

首页 > 解决方案 > REST API - 创建资源和嵌套资源最佳实践

rest - REST API - 创建资源和嵌套资源最佳实践

问题描述

我有一个关于 REST API 的问题，尤其是关于资源创建（和嵌套资源）的问题。

假设我们有以下“GET”路由：

GET /recipes/1
{
  "id": 1,
  "name": "Crepes",
  "ingredients": [
    {"id": 1, "name": "Flour", "quantity": 100},
    {"id": 2, "name": "Milk", "quantity": 15},
    ...
  ]
}

GET /recipes/1/ingredients/1
{
  "name": "Flour",
  "quantity": 100,
  "details": "...",
  ...
}

我的问题是：最佳实践/设计是POST /recipes什么？（假设我们要创建之前的配方）

  1. 我们只打了 1 个电话：
POST /recipes
body = {
  "name": "Crepes",
  "ingredients": [
    {"name": "Flour", "quantity": 100, ...},
    {"name": "Milk", "quantity": 15, ...}
    ...
  ]
}

==> 配方和配料同时创建

  1. 我们调用 1 次来获取食谱，并调用 X 来获取成分：
POST /recipes
body = {
  "name": "Crepes"
}

POST /recipes/1/ingredients
body = {
  "name": "Flour",
  "quantity": 100,
  ...
}

...

==> 配方和成分是一个接一个地创建的

那么，资源和嵌套资源的最佳实践/设计是什么？

谢谢 ！

标签： restpost

解决方案

TL; DR——是的，你想向服务器发送一个请求，并允许服务器“创建”尽可能多的资源来支持未来的工作。

HTTP 中潜在的复杂问题是缓存。REST中的一个重要思想是它“允许在对该概念的任何实现存在之前对该概念进行引用”。

在 web 的上下文中，这意味着客户端可以GET /recipes/1/ingredients/1在该资源具有表示之前潜在地。当服务器以404 Not Found响应时，该响应是可缓存的。

这里有一个重要的想法：缓存失效具有非常精确的语义；成功的POST /recipes请求将使/recipes资源的任何本地缓存副本无效，但不会影响/recipes/1or的缓存副本/recipes/1/ingredients/1。

这意味着如果您在 API 前面放置一个通用反向代理，则代理上不同资源的副本不会一起更新。因为不同的资源不会失效，所以在多种情况下，多个资源的消费者会看到不一致的信息。

好消息是，作为原始服务器，您不仅可以控制资源的表示，还可以控制缓存元数据。因此，您可以将缓存策略调整为在相互冲突的设计压力之间取得最佳折衷。

在实践中，您可能会发现批量创建资源不是问题，因为客户端几乎没有理由在资源创建之前获取它。批量更新问题更大。

推荐阅读