Question

我正在寻找有关REST API标准模式的讨论。我有一个NoSQL风格的实现......也就是说，有一个表包含对象（议程项），每个对象都有一个对另一个表（Documents）中记录的引用列表。在我正在构建的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表示包括一个请求中的所有文档详细信息。我将此称为 trashy ，因为有额外的信息不是来自表格。

[
   {
    "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"
      }]
    }
]

后一种格式是

方便，因为在单个请求中，您可以获得向用户显示良好显示所需的所有信息。
效率低下因为有关一个文档的信息会被发送两次。（通常情况下，这个例子可能比这个例子多得多。）
trashy 因为如果您在更新命令中回复此相同格式，则应忽略有关该文档的额外详细信息 - 只有该ID与更新相关。如果您要更改此结构中的文档名称，则可能不会使用新名称更新该文档。由于文档在此结构中出现两次，因此可能在不同的点上具有不同的名称。

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

第三种选择是混合：你得到了填充形式的胖子，但是你要退回瘦的非规范化形式。我宁愿不为同一个对象使用两种不同的格式。我正在使用AngularJS，并且获取的JSON对象直接在JS对象树中进行转换，并且将完全相同的东西放回去是非常方便的。

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

此外，在使用AngularJS时，将其他成员放入UI的集合中非常方便，例如选择＆＃34;选择＆＃34;旗。再说一次，也许我太懒了，但是在发回更新之前从每条记录中剥离这个选定的标记是很麻烦的，如果我可以假设那些额外的“无用的”＆＃39;数据成员将被忽略它使编码更容易。可以假设您的REST API会忽略额外的元素吗？

Answer 1

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

所以 - 实际上，没有“无用的”数据成员。第二种方法更好 - 第一种方法更多是来自关系数据库的宿醉。

但是，在频繁更新的情况下，第一种方法可以更好地实现性能。

REST API是否应将来自多个表的信息合并到JSON响应中？

1 个答案: