未来证明：删除 JSON 信封是当前的最佳实践吗？

Question

我已经阅读了关于您是否应该删除 JSON 请求或回复中的信封的相互矛盾的“意见”。

例子：

{
    "data": {
        "foo" : "bar",
        "baz" : "Xyzzy"
    }
}

应该（据说）写成：

{
    "foo" : "bar",
    "baz" : "Xyzzy"
}

但是，按照 SOLID 原则，这个结构应该对扩展开放，对修改关闭。因此，移除信封将是一个坏主意。对？

如果稍后我决定需要向入站 JSON 信息添加更多信息，那么这样做会更简洁：

{
    "data": {
        "foo" : "bar",
        "baz" : "Xyzzy"
    },

    "extended-data": {
        "abc" : 123
    }
}

比这样做：

{
    "foo" : "bar",
    "baz" : "Xyzzy",
    "abc" : 1234
}

前者允许先前编写的代码，它会查找“数据”节点以执行而不会出现故障或更改。后者要求重新编写代码以查找新值。

当前的最佳实践是什么，请提供您的来源：我需要公认的标准而不是意见。

更新：

回答异议：“如果添加字段，则必须更改代码。”

并不真地。我不必更改代码来处理新字段，我只需要为新数据添加一个新处理程序：

例子：

function delegateTask($json) {
    $this->doSomething($json->data);
}

扩展后：

function delegateTask($json) {
    $this->doSomething($json->data);
    $this->doSomethingElse($json->extended);
}

如果我只使用 HTTP 作为信封，我必须重新编写 doSomething()。如果我采用 SOLID 方式，我只需要添加一个查看新数据的函数。

不重复： 这个问题不是什么时候在我的 REST API 中应该使用信封？如果我在一个地方使用它，我应该一直使用它吗？因为这个问题专门涉及与信封相关的代码的 SOLID 原则和扩展。不仅仅是返回给客户端的错误消息。

Answer 1

信封是命名空间。命名空间是模块化设计和关注点分离的好工具。

考虑用于使用 JSON API 的事物类型。网格等。从分页和其他元数据中分离实际数据不那么脆弱。

我认为您可以将 SOLID 中的“I”应用于此。

接口隔离原则——“许多特定于客户端的接口优于一个通用接口。

使用信封，我可以采用任何 API 模式并将其与我选择的任何 Javascript 组件结合起来，而无需担心冲突或必须重命名字段才能使事情发挥作用。

这同样适用于 API 聚合。我可以在一次调用中组合 2 个单独的结果，以提供对特定用途最有效的“视图模型”。更容易与信封聚合。

看看像OData这样的标准，该标准背后有很多聪明人。

至于扩展和生命周期，我会简单地发布一个 v2 API 并维护旧的 API，直到它被弃用。API 的多版本控制是常见做法（例如：eBay、Salesforce）。