我正在处理与后端思想REST API通信的应用程序的前端。后端是某种独立设备，而不是标准的Web服务器，因此它不是那么强大（但可以运行php）。 API非常通用，并返回类似键值对的值，例如
[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]
我面临的问题是它不考虑类型，它返回所有内容，如引号中的字符串（数字：“123”，布尔值：“1”）。最近我要求改变（我的论点是手动类型转换是不必要的工作，必须由每个客户端应用程序完成，如果服务器可以做到，可以避免），但我需要一些更有说服力的论点。我的要求的一些反驳是：
那么说服我的同事说JSON响应中的类型对我和他们来说都是好事可能是一些好的论据？
由于
答案 0 :(得分：3)
RESTful communcation和JSON是两回事。 JSON只是数据的格式，可以是XML，甚至是CSV或自定义格式，这不会删除RESTful方面。
JSON本身由几乎所有javascript库处理，它们处理服务器通信，无需进行解析，转换很少（可能是时间戳中的日期对象和其他类型的东西）。
在服务器端，有很多库可以为你处理JSON，以及它们如何生成键值的东西？一个内省的通用代码，还是为所有类编写了大量的序列化程序？这可能会导致很多技术和不必要的代码编写和测试。
KISS并不意味着保持它完全愚蠢而且不考虑任何事情。布尔值在字符串中有一个数字，而数字作为字符串没有什么简单的开发者，它只是处理所有对象转换的地狱。如果您需要检查数据约束，当您必须验证每个字段（测试数字是否为数字，......）时，这将导致自己重复。
更简单的事情是不要编写自己的库，将所有转换为字符串，可能性能低于专用库。它是用于为您完成工作的库。
如果你把all作为类型对象写，你后端的json反序列化器会为你做一部分验证，布尔值将是一个布尔值，一个数字将是一个数字，如果你有很多验证要做，这导致编写更少的代码来执行所有检查。
客户端我想有很多代码可以处理所有这些键/值的东西并转换值。如果你进行单元测试，这会减慢开发速度，它会增加很多测试。
GUI设计者有责任理解每个参数的上下文
这是真的，但我觉得提供格式良好的数据是服务器的责任。执行格式将导致快速失败，这是一件好事。他们是否因为这种通用格式而没有任何生产问题？他们没有适当的JSON。
Personnaly我在服务器上的JSON代码是Java注释和一个自定义序列化器，仅此而已。我想知道他们编写了多少代码来序列化/反序列化和转换类型。
答案 1 :(得分：1)
首先，使用以下数据格式[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]的想法有点愚蠢，与{ "key1": "some value", "key2": "1234" }基本相同。
关于这些要点，你的同事做了： 1.虽然这确实是基于文本的传输和对象的字符串表示与实际对象之间的转换必须完成，但如果要传输对象，则无需递归遍历键/值对树。其他复杂类型作为值。
让我们假装您必须传输以下数据：
{ "key1": { "x": 10, "y": 20 } }
如果你要将内部对象编码为字符串，你会得到这样的东西：
"{ \"key1\": \"{ \"x\": \"10\", \"y\": \"20\" }\" }"
如果您的值转换为字符串，则必须首先在整个对象上调用JSON.parse以及可能在该对象内部存储为文本的对象，这需要树的递归遍历。另一方面，当使用本机类型（例如对象，数字和数组）作为值时，只需调用一次JSON.parse即可获得相同的效果（内部是递归的，但更好的是自己管理它）。
第二点是有效的，但我觉得任何服务都应该以即用形式返回数据，或者至少尽可能准备好。如果您的服务为您提供了一些原始XML而不是解析和准备好的数据，那么它不会是愚蠢的吗？同样的原则适用于此。
我觉得你的朋友只是懒得试图用KISS原则掩盖他们的屁股。很可能他们的服务器代码具有以正确类型对值进行编码所需的所有信息，这在客户端更难实现。所以他们的第三点似乎是一个明目张胆的我们太懒了所以你必须这样做＆＃39;的事情。