为什么要在 JSON 响应中使用类型

RESTful 通信和 JSON 是两个不同的东西。JSON只是数据的格式，它可以是XML，甚至是CSV或自定义格式，这不会删除RESTful方面。

JSON几乎由所有处理服务器通信的javascript库原生处理，无需解析，几乎没有转换（可能是时间戳中的日期对象和其他类型的东西）。

在服务器端，也有很多库可以为您处理 JSON，以及它们如何生成键值？具有内省功能的通用代码，还是它们为所有类编写了大量序列化程序？这可能会导致编写和测试大量技术和不必要的代码。

KISS并不是要让它完全愚蠢，什么都不去想。让布尔值在字符串中有一个数字，而数字作为字符串作为开发者并不简单，它只是处理所有对象转换的地狱。如果您需要检查数据约束，这将导致您必须验证每个字段（测试数字是否为数字,...）时重复。

更简单的事情是不要编写自己的库，将所有库都转换为字符串，其性能可能不如专用库。这是为您完成这项工作的二手库。

如果你把所有的东西都写成类型化对象，你在后端的json反序列化器会为你做一部分验证，布尔值就是布尔值，数字就是数字，如果你有很多验证要做，这会导致更少的代码来执行所有的检查。

客户端我想有很多代码来处理所有这些键/值的东西并转换值。这会减慢开发速度，如果您执行单元测试，则会增加大量测试工作。

GUI 设计人员有责任了解每个参数的上下文

嗯，这是真的，但我觉得提供格式良好的数据是服务器的责任。强制执行格式将导致快速失败，这是一件好事。由于这种通用格式，他们从未遇到过任何生产问题吗？他们不会使用适当的 JSON。

我个人在服务器上的 JSON 代码是 Java 注释和一个自定义序列化程序，仅此而已。我想知道他们写了多少代码来序列化/反序列化和转换类型。

First of all, the idea of using the following data format is kinda stupid and is basically the same as . [{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]{ "key1": "some value", "key2": "1234" }

In regards to the points, your colleagues made: 1. While this is indeed text-based transfer and conversion between the string representation of your object and an actual object has to be done, there would be no need to recursively walk the tree of key/value pairs if you were to transfer objects or other complex types as values.

Let's pretend that you have to transfer following piece of data:

{ "key1": { "x": 10, "y": 20 } }

if you were to encode inner object as string you would get something like this:

"{ \"key1\": \"{ \"x\": \"10\", \"y\": \"20\" }\" }"

If your value was converted to string, you'd have to call JSON.parse on the entire object first as well as on the object that was possibly stored as text inside that object, which requires recursive walking of the tree. On the other hand, when using native types (such as objects, numbers and arrays) as values you would achieve the same effect with just one call to JSON.parse (which would internally be recursive, but still better that managing it yourself).

Second point is valid but I feel like any service should return the data in ready-to-use form or at least as ready as it can be. Wouldn't it be stupid if your service gave you some piece of raw XML instead of parsed and prepared data? Same principle applies here.

I feel like your friends are just being lazy trying to cover their butts with KISS principle here. It is very likely that their server code has all the info it needs to encode the values in their proper types, which would be much harder to do on the client side. So their third point seems like a blatant 'we are too lazy so you have to do it' thing.