REST API 是否应该将来自多个表的信息组合成 JSON 响应？答案

【问题标题】：Should REST API combine information from multiple tables into JSON response?REST API 是否应该将来自多个表的信息组合成 JSON 响应？
【发布时间】：2015-05-23 16:15:45
【问题描述】：

我正在寻找有关 REST API 标准模式的讨论。我有一个 NoSQL 风格的实现……也就是说，有一个表包含对象（议程项目），每个对象都有一个对另一个表（文档）中记录的引用列表。在我正在构建的 UI 中，用户可以选择现有的附件，并将其附加到议程项目。在此 UI 中，您不能创建新的 Document 对象，只能引用现有的对象。由于这是一个 NoSQL 实现，因此我没有加入 doc_id 上的表，而是将它们作为单独的表进行操作。

有两种方法可以实现 REST api。第一个是非规范化，其中一个请求获取议程项目记录，第二个请求获取文档。使用议程项目中的 doc_id，在客户端中您可以找到相关的文档信息。

[
   {
    "name": "Agenda Item 1",
    "attachments": ["11556", "87544"]
    },
   {
    "name": "Agenda Item 2",
    "attachments": ["33445", "87544"]
    }
]

文档列表为：

[
   {
    "name": "Design Spec A.ppt",
    "id": "11556"
   },
   {
    "name": "Design Guidelines.doc",
    "id": "33455"
   },
   {
    "name": "User Studies.xls",
    "id": "87544"
   },
]

第二种方法是构建 REST，以便议程项目的 JSON 表示在一个请求中包含所有文档详细信息。我将其称为垃圾，因为有额外的信息不是来自表格。

[
   {
    "name": "Agenda Item 1",
    "attachments": [{
        "name": "Design Spec A.ppt",
        "id": "11556"
      }, 
      {
        "name": "User Studies.xls",
        "id": "87544"
      }]
    },
   {
    "name": "Agenda Item 2",
    "attachments": [{
        "name": "Design Guidelines.doc",
        "id": "33455"
      }, 
      {
        "name": "User Studies.xls",
        "id": "87544"
      }]
    }
]

后一种格式是

方便客户端，因为在一个请求中，您可以获得向用户呈现漂亮显示所需的所有信息。
效率低 因为一个文档的信息被发送了两次。（一般来说，它可能比这个例子提供更多的信息。）
垃圾，因为如果您在更新命令中 POST 相同的格式，则有关文档的额外详细信息应被忽略 - 只有 id 与更新相关。如果您要更改此结构中的文档名称，则该文档可能不会使用新名称进行更新。由于该文档在此结构中出现了两次，因此它可能在不同的位置具有不同的名称。

似乎规则可能是您在获取信息时添加额外的文档信息，而在 PUTTING 或 POSTING JSON 结构时忽略该额外信息。

第三种选择是混合：你得到了脂肪填充的表格，但你把瘦的非规范化表格放回去了。我不希望同一个对象有两种不同的格式。我正在使用 AngularJS，获取的 JSON 对象直接在 JS 对象树中转换，将完全相同的东西放回去非常方便。

我已经实现了这两种方法，两种方法都有效，但我想指出一个讨论：每种方法的智慧是什么？

此外，当使用 AngularJS 时，将其他成员放入 UI 集合中非常方便，例如“选定”标志。同样，也许我太懒了，但是在发回更新之前从每条记录中删除这个选定的标志是一件麻烦事，如果我可以假设额外的“无用”数据成员将被忽略，它会使编码更容易。可以假设您的 REST API 会忽略额外的元素吗？

【问题讨论】：

标签： angularjs json rest nosql

【解决方案1】：

在发布更新之前确实不需要删除文档的任何元素/字段 - 您只需在 json 中包含需要更新的内容并触发它。未包含的内容将保留在数据库中。

所以 - 实际上，没有“垃圾”数据成员。第二种方法更好——第一种更像是关系数据库的遗留问题。

但是，在更新频繁的情况下，第一种方法在性能方面可能会更好。

【讨论】：