爲什麼在JSON響應中使用類型

Question

我正在研究與後端思想REST API進行通信的應用程序的前端。後端是某種獨立設備，不是標準的Web服務器，因此它不是很強大（但可以運行PHP）。該API是非常通用的，並返回類似鍵值對的值，例如

[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }] 

我面對的問題是，它不考慮類型，它返回一切都像在引號中的字符串（數字：「123」，布爾：「1」）。最近我要求改變（我的觀點是，手動類型轉換是不必要的工作，必須由每個客戶端應用程序來完成，並且如果服務器可以做到則可以避免），但是我需要一些更有說服力的論點。一些反駁了我的請求有：

1. RESTful的通信是本身作爲字符串（因此無論，如果 轉移1或「1」 - 一個客戶端類型轉換已到 完成）
2. GUI設計人員有責任瞭解每個參數的背景
3. 後端遵循KISS原則，將所有內容保留爲字符串，並且不需要在背面進行額外的處理，並且可以在GUI上完成通常在更強大的PC上

那麼，說服我的同事們說JSON響應中的類型對我和他們來說都是好事，這有什麼好的理由呢？

謝謝

Answer 1

RESTful communcation和JSON是兩個不同的東西。 JSON只是數據的格式，可能是XML或甚至CSV或自定義格式，但這並不能消除REST風格。

JSON本質上是由處理服務器通信，不需要解析，幾乎不需要轉換（可能是時間戳中的日期對象和其他類型的東西）的所有JavaScript庫處理的。

在服務器端有很多庫可以爲您處理JSON，以及它們如何生成鍵值對象？一個帶自省的泛型代碼，或者他們爲所有類寫了大量的序列化程序嗎？這可能會導致大量的技術和無用的代碼編寫和測試。

KISS並不意味着保持它完全愚蠢，不要去想任何事情。布爾值有一個字符串中的數字和數字作爲字符串沒有什麼簡單的作爲一個開發人員，它只是地獄來處理所有對象的轉換。如果您需要檢查數據限制，這將導致重複自己當您將不得不驗證每個字段（測試數字是一個數字，...）。

更簡單的事情不是編寫自己的庫，它將全部轉換爲字符串，並且可能具有較低的專用庫性能。這是使用圖書館爲你做的工作。

如果你寫的所有的類型的對象，在後臺的JSON解串器會爲你做驗證的一部分，一個布爾值將是一個布爾值，數字將是一個數字，如果你有很多的驗證辦，這導致更少的代碼來執行所有檢查。

客戶端我想有很多代碼來處理所有這些鍵/值的東西，並轉換值。這會降低開發速度，如果你執行單元測試，它會增加很多測試。

它是GUI設計師的責任，瞭解每個參數

的情況下嗯，這是事實，但我覺得也提供格式化的數據是服務器的責任。執行格式將導致快速失敗，這是一件好事。由於這種通用格式，他們是否從未遇到任何生產問題？他們不會用適當的JSON。

Personnaly服務器上的我的JSON代碼是Java註釋和一個自定義序列化器，僅此而已。我不知道他們寫了多少代碼來序列化/反序列化和轉換類型。

Answer 2

首先，使用以下數據格式[{ 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原則掩蓋他們的屁股。他們的服務器代碼很有可能具有所需的所有信息，以便將它們的值編碼爲適當的類型，這在客戶端會更難。所以他們的第三點看起來像一個公然的'我們太懶了，所以你必須這樣做'的事情。