Question

假设我们正在构建具有两个视图的单页应用：列表视图和详细视图。

在列表视图中，我们提供了一个只包含其名称和更多最小数据的对象列表。

在详细视图中，我们提供了特定对象的所有可能字段。

因此问题是：当我们获得/api/items/时，我们是否应该对列出的对象的所有字段进行JSON编码，或者只列出列表视图中的字段？

换句话说，如果我们显示像

这样的食物清单

Name     Price
Potato   1
Milk     2

我们的API是否需要像这样响应JSON：

{ 
    [
         {
             "name": "Potato",
             "quantity": "1 kg",
             "origin": "Egypt", 
             "manufacturer": "Egypt Farmers",
             "price": 1,
             "packaging": "String bag",
             "_type": "Food"
         },
         {
             "name": "Milk",
             "quantity": "1 litre",
             "origin": "Finland", 
             "manufacturer": "Valio",
             "price": 2,
             "packaging": "Tetra Pak",
             "_type": "Food"
         },
    ]
}

或者像这样：

{ 
    [
         {
             "name": "Potato",
             "price": 1,
             "_type": "Food"
         },
         {
             "name": "Milk",
             "price": 2,
             "_type": "Food"
         },
    ]
}

Answer 1

RESTful API应该专注于所代表的资源，而不一定是如何使用这些资源。

在主/详细方案中，通常主服务器将包含主对象的详细信息，并包含其详细信息的列表（包括每个详细信息资源的API链接。所以/ api / items /可能看起来像这样：

{
    items: [
       { name: 'item 1', href: '/api/items/1' },
       { name: 'item 2', href: '/api/items/2' }
    ]
}

详细信息资源将包含项目列表中单个项目的属性。所以/ api / items / {itemName} api可能如下所示：

{
    name: 'item 1', 
    color: 'blue', 
    weight: 100,
    id: '/api/items/1'
}

所以这可能最接近你的第二个场景。这个模型有许多优点：它可能与你的api访问的域模型匹配，它使每个api非常简单和单一用途，它很容易扩展，甚至非常大的列表。缺点是它可能会导致客户端更加复杂。

Answer 2

通常的答案可能是：一切都取决于;）

如果连接受限或不稳定（例如LTE或甚至wifi等移动连接），最好的办法是返回填充所有字段的整个资源列表，并在两个视图上使用相同的数据。在我工作的公司中，我们经常采用这种方法，因为我们的后端几乎总是为移动应用程序提供数据。
第二个想法是使用一种称为字段或资源扩展的机制。通常，对端点发出请求，并且要返回的资源字段包含在此请求中：
```
/api/items?fields=(name, quantity, origin, whatever)
```
此机制非常方便，因为您可以使用此端点来服务多个视图而不会导致任何性能损失。
我个人使用两个端点。内置字段/资源扩展机制的/api/items/端点（具有可扩展的有限字段列表），第二个端点/api/items/{itemID}/返回包含所有数据的特定项目。这也是最RESTful的方法。

REST API：响应JSON中对象列表中的对象字段

2 个答案: