来自 REST API 的 JSON 响应中是否应该包含空值？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/15686995/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should null values be included in JSON responses from a REST API?
提问by Dennis Laumen
I'm in the process of designing and developing a RESTful API. I'm taking a pragmatic, resource oriented approach to the API (resource oriented, uniform interface, addressability, but no real HATEOAS). One point I'm not sure about though is how to approach null values in objects.
我正在设计和开发 RESTful API。我正在对 API 采取务实的、面向资源的方法（面向资源、统一接口、可寻址性，但没有真正的 HATEOAS）。我不确定的一点是如何处理对象中的空值。
Should I include fields with null values in the APIs responses?
我应该在 API 响应中包含具有空值的字段吗？
Example:
例子：
{
"fieldA": "AAA",
"fieldB": null
}
Or, should I just leave out these fields altogether if the system has no data for these fields?
或者，如果系统没有这些字段的数据，我是否应该完全忽略这些字段？
Example:
例子：
{
"fieldA": "AAA"
}
采纳答案by Pete
There was a discussion about this recently on API-Craft. The general consensus was there is potentially a semantic difference between the omissionof a value, versus an inclusion of a null value.
最近在API-Craft上有一个关于这个的讨论。普遍的共识是，省略值与包含空值之间可能存在语义差异。
If there is no semantic value to be gained for your specific use case, then I would say look at your target consumers of the API, and think about whether omitting the value will cause them problems.
如果您的特定用例没有获得语义价值，那么我会说看看您的 API 的目标消费者，并考虑省略该值是否会导致他们出现问题。
回答by tkruse
There is no clear winner. And because there is not, clients should never technically depend on any convention about this, clients should not expect either shape.
没有明显的赢家。因为没有，客户在技术上不应该依赖任何关于此的约定，客户不应该期望任何一种形状。
- removing null values to reduce bandwidth usageis commonly not justified (unless the number of null fields is large and the bandwidth noticeably suffers).
- removing null values to allow human readers to more easily see actual valuesis not commonly justified, APIs are not man-machine interfaces
- keeping null values to allow human readers to more easily see document structureis not commonly justified, APIs are not man-machine interfaces, and API responses are not API documentation
- keeping null values to allow dirty clients to parse the json in specific waysis commonly not justified, clients should be written cleanly as tolerant readers
- keeping null values only where the corresponding create method (POST/PUT) requires explicit passing of nullwould make sense, but is commonly difficult to achieve
- keeping the output same as the request during creationcould make sense when each document has its own owning client, but is commonly difficult to achieve
- A special case to consider is partial responses triggered by something like
?fields=foo,barwhere returning nulls for all other fields seems a bit counter-intuitive
- 删除空值以减少带宽使用通常是不合理的（除非空字段的数量很大并且带宽明显受到影响）。
- 删除空值以让人类读者更容易看到实际值通常是不合理的，API 不是人机界面
- 保留空值以让人类读者更容易地看到文档结构通常是不合理的，API 不是人机界面，API 响应不是 API 文档
- 保留空值以允许脏客户端以特定方式解析 json通常是不合理的，客户端应该作为宽容的读者干净地编写
- 仅在相应的创建方法 (POST/PUT) 需要显式传递 null 时才保留 null 值是有意义的，但通常难以实现
- 当每个文档都有自己的客户端时，在创建过程中保持输出与请求相同是有意义的，但通常很难实现
- 一个需要考虑的特殊情况是由诸如
?fields=foo,bar返回所有其他字段的空值似乎有点违反直觉的事情触发的部分响应
