为什么在 JSON 响应中使用类型
Why to use types in JSON responses
我正在开发与后端思想 REST 通信的应用程序的前端 API。后端是某种独立设备，不是标准的 Web 服务器，因此它不是那么强大（但可以 运行 php）。 API 非常通用，returns 值类似于键值对，例如
[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]
我面临的问题是它不考虑类型，它 returns 一切都像引号中的字符串（数字：“123”，布尔值：“1”）。最近我要求改变（我的论点是手动类型转换是不必要的工作，必须由每个客户端应用程序完成，如果服务器可以做到则可以避免）但我需要一些更有说服力的论据。对我的请求的一些反驳是：
- RESTful 通信本身是一个字符串（所以无论如何，如果
传输 1 或“1”——客户端类型转换必须
完成）
- GUI 设计者有责任了解每个参数的上下文
- 后端遵循 KISS 原则，将所有内容都保留为字符串，并且不需要在后端进行额外处理，并且可以在 GUI 上完成，这通常在功能更强大的 PC 上
那么有什么好的论据可以说服我的同事输入 JSON 回复对我和他们都是好事呢？
谢谢
RESTful 通信和 JSON 是两种不同的东西。 JSON 只是数据的格式，它可以是 XML 甚至 CSV 或自定义格式，这不会删除 RESTful 方面。
JSON 由几乎所有处理服务器通信的 javascript 库本地处理，无需解析，很少转换（可能是时间戳中的日期对象和其他类型的东西）。
在服务器端，有很多库也可以为您处理 JSON，它们如何生成键值对？具有自省功能的通用代码，还是他们为所有 类 编写大量序列化程序？这会导致编写和测试大量技术和不必要的代码。
KISS并不是说要一直傻到什么都不想。让布尔值在字符串中有一个数字，而作为字符串的数字对于开发人员来说并不简单，处理所有对象转换简直就是地狱。如果您需要检查数据约束，这将导致 repeat yourself 当您必须验证每个字段时（测试数字是否为数字，...）。
更简单的事情是不要编写自己的将所有内容转换为字符串的库，其性能可能不如专门的库。它是为你做这项工作的二手图书馆。
如果你把所有的东西都写成类型对象，你在后端的 json 反序列化器会为你做一部分验证，一个布尔值就是一个布尔值，一个数字就是一个数字，如果你有一个需要做很多验证，这导致编写执行所有检查的代码更少。
客户端我想有很多代码可以处理所有这些 key/value 事情并转换值。这会减慢开发速度，如果您执行单元测试，它会增加很多测试工作。
it is the responsibility of the GUI designer to understand the context of each parameter
的确如此，但我觉得提供格式正确的数据是服务器的责任。强制执行一种格式将导致快速失败的实践，这是一件好事。由于这种通用格式，他们从未遇到过任何生产问题吗？他们不会用适当的 JSON.
个人而言，我在服务器上的 JSON 代码是 Java 注释和一个自定义序列化程序，仅此而已。我想知道他们为 serialize/deserialize 和转换类型写了多少代码。
首先，使用下面的数据格式[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]的想法有点蠢，和{ "key1": "some value", "key2": "1234" }基本一样。
关于几点，您的同事提出：
1. 虽然这确实是基于文本的传输，并且必须完成对象的字符串表示和实际对象之间的转换，但如果要传输，则无需递归遍历 key/value 对树对象或其他复杂类型作为值。
假设您必须传输以下数据：
{ "key1": { "x": 10, "y": 20 } }
如果您将内部对象编码为字符串，您会得到如下内容：
"{ \"key1\": \"{ \"x\": \"10\", \"y\": \"20\" }\" }"
如果您的值已转换为字符串，则必须首先对整个对象以及可能作为文本存储在该对象内的对象调用 JSON.parse，这需要递归遍历那个树。另一方面，当使用本机类型（例如对象、数字和数组）作为值时，您只需调用一次 JSON.parse 即可达到相同的效果（这在内部是递归的，但仍然比自己管理它更好).
第二点是正确的，但我觉得任何服务都应该 return 数据以随时可用的形式或至少尽可能准备好。如果您的服务给您一些原始 XML 而不是经过解析和准备的数据，那不是很愚蠢吗？同样的原则也适用于此。
我觉得你的朋友们只是懒惰地试图用 KISS 原则来掩盖他们的屁股。他们的服务器代码很可能拥有将值编码为正确类型所需的所有信息，这在客户端很难做到。所以他们的第三点似乎是一个公然的'we are too lazy so you have to do it'事情。
我正在开发与后端思想 REST 通信的应用程序的前端 API。后端是某种独立设备，不是标准的 Web 服务器，因此它不是那么强大（但可以 运行 php）。 API 非常通用，returns 值类似于键值对，例如
[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]
我面临的问题是它不考虑类型，它 returns 一切都像引号中的字符串（数字：“123”，布尔值：“1”）。最近我要求改变（我的论点是手动类型转换是不必要的工作，必须由每个客户端应用程序完成，如果服务器可以做到则可以避免）但我需要一些更有说服力的论据。对我的请求的一些反驳是：
- RESTful 通信本身是一个字符串（所以无论如何，如果 传输 1 或“1”——客户端类型转换必须 完成）
- GUI 设计者有责任了解每个参数的上下文
- 后端遵循 KISS 原则，将所有内容都保留为字符串，并且不需要在后端进行额外处理，并且可以在 GUI 上完成，这通常在功能更强大的 PC 上
那么有什么好的论据可以说服我的同事输入 JSON 回复对我和他们都是好事呢？
谢谢
RESTful 通信和 JSON 是两种不同的东西。 JSON 只是数据的格式，它可以是 XML 甚至 CSV 或自定义格式，这不会删除 RESTful 方面。
JSON 由几乎所有处理服务器通信的 javascript 库本地处理，无需解析，很少转换（可能是时间戳中的日期对象和其他类型的东西）。
在服务器端，有很多库也可以为您处理 JSON，它们如何生成键值对？具有自省功能的通用代码，还是他们为所有 类 编写大量序列化程序？这会导致编写和测试大量技术和不必要的代码。
KISS并不是说要一直傻到什么都不想。让布尔值在字符串中有一个数字，而作为字符串的数字对于开发人员来说并不简单，处理所有对象转换简直就是地狱。如果您需要检查数据约束，这将导致 repeat yourself 当您必须验证每个字段时（测试数字是否为数字，...）。
更简单的事情是不要编写自己的将所有内容转换为字符串的库，其性能可能不如专门的库。它是为你做这项工作的二手图书馆。
如果你把所有的东西都写成类型对象，你在后端的 json 反序列化器会为你做一部分验证，一个布尔值就是一个布尔值，一个数字就是一个数字，如果你有一个需要做很多验证，这导致编写执行所有检查的代码更少。
客户端我想有很多代码可以处理所有这些 key/value 事情并转换值。这会减慢开发速度，如果您执行单元测试，它会增加很多测试工作。
it is the responsibility of the GUI designer to understand the context of each parameter
的确如此，但我觉得提供格式正确的数据是服务器的责任。强制执行一种格式将导致快速失败的实践，这是一件好事。由于这种通用格式，他们从未遇到过任何生产问题吗？他们不会用适当的 JSON.
个人而言，我在服务器上的 JSON 代码是 Java 注释和一个自定义序列化程序，仅此而已。我想知道他们为 serialize/deserialize 和转换类型写了多少代码。
首先，使用下面的数据格式[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]的想法有点蠢，和{ "key1": "some value", "key2": "1234" }基本一样。
关于几点，您的同事提出： 1. 虽然这确实是基于文本的传输，并且必须完成对象的字符串表示和实际对象之间的转换，但如果要传输，则无需递归遍历 key/value 对树对象或其他复杂类型作为值。
假设您必须传输以下数据：
{ "key1": { "x": 10, "y": 20 } }
如果您将内部对象编码为字符串，您会得到如下内容：
"{ \"key1\": \"{ \"x\": \"10\", \"y\": \"20\" }\" }"
如果您的值已转换为字符串，则必须首先对整个对象以及可能作为文本存储在该对象内的对象调用 JSON.parse，这需要递归遍历那个树。另一方面，当使用本机类型（例如对象、数字和数组）作为值时，您只需调用一次 JSON.parse 即可达到相同的效果（这在内部是递归的，但仍然比自己管理它更好).
第二点是正确的，但我觉得任何服务都应该 return 数据以随时可用的形式或至少尽可能准备好。如果您的服务给您一些原始 XML 而不是经过解析和准备的数据，那不是很愚蠢吗？同样的原则也适用于此。
我觉得你的朋友们只是懒惰地试图用 KISS 原则来掩盖他们的屁股。他们的服务器代码很可能拥有将值编码为正确类型所需的所有信息，这在客户端很难做到。所以他们的第三点似乎是一个公然的'we are too lazy so you have to do it'事情。