JSON vs YAML：為何JSON能穩坐資料交換的寶座？

「明明YAML對人類來說更易讀，為何API通訊卻幾乎都只使用JSON？」 「YAML的優勢在哪裡？JSON又是基於什麼原因成為了標準？」

JSON vs YAML 中世紀之戰

1. 資料格式戰爭的序幕

過去，開發人員需要一套「共通規範」來讓系統之間交換資料。初期，XML佔據了主導地位。

<person>
    <name>Alice</name>
    <age>25</age>
    <skills>
        <skill>Python</skill>
        <skill>Django</skill>
    </skills>
</person>

然而，XML因需要一一關閉標籤而顯得過於冗長和笨重，閱讀起來也令人疲憊。此時，JSON和YAML作為替代方案應運而生。

2. JSON：成為網頁資料交換的標準

2001年，道格拉斯·克拉克福特 (Douglas Crockford) 從JavaScript的物件表示法中獲得靈感，創造了JSON。其核心理念是「盡可能輕量化，便於機器讀取」。

JSON的成功秘訣顯而易見： * 極致輕量： 無需多餘裝飾，僅傳遞資料本身。 * 與網頁完美契合： 瀏覽器 (JavaScript) 無需額外函式庫即可直接轉換為物件。 * 直觀的對應關係： 與Python的Dict、JS的Object等現代程式語言的資料結構幾乎完全一致。

特別是隨著REST API成為網頁主流，JSON實際上已成為全球通用的語言。

3. YAML：為人類閱讀而生的格式

相較於JSON，也有陣營更專注於「人類閱讀的樂趣」。抱持著「能否在沒有大括號或引號的情況下，寫出更簡潔的內容？」的疑問，YAML應運而生。

name: Alice
age: 25
skills:
  - Python
  - Django

YAML的特點非常鮮明： * 極高的可讀性： 基於縮排 (Indentation) 的特性，使得文字內容非常整潔。 * 支援註解 (#)： 相較於JSON，能夠添加「說明」是一大優勢。 * 設定檔的強者： 憑藉其卓越的可讀性，它完全主導了Kubernetes、Docker、GitHub Actions等基礎設施設定的格式。

然而，為何在資料交換 (API) 領域，YAML未能超越JSON呢？

4. YAML在資料交換中落敗的現實原因

首先，縮排的嚴格性 (Space vs Tab) JSON使用括號來定義結構，而YAML則是由看不見的空白字元來決定結構。在交換複雜資料時，一個錯誤的空白字元就可能導致難以排查的錯誤。

其次，解析速度與資源消耗 JSON語法簡單，其解析器輕巧且快速。相較之下，YAML語法龐大且複雜（甚至包含程式碼執行功能），解析時會消耗更多記憶體和CPU。這對於處理大量資料的API環境來說是致命的。

第三，安全問題 YAML不僅能表示單純的資料，還能包含直接呼叫特定語言物件的功能。這可能導致遠端程式碼執行 (RCE) 等安全漏洞，因此不適合用於與不特定多數對象交換資料的API。

5. 歸根結底是「適材適用」的問題

如果說JSON是資料交換的王者，那麼YAML就是設定檔的王者，兩者各自穩固了自身的領域。

  • 何時使用JSON： 網頁API通訊、NoSQL資料庫儲存、客戶端與資料傳輸時。
  • 何時使用YAML： 專案設定檔 (docker-compose.yml)、CI/CD腳本、需要人工管理的檔案。

即使在Django Rest Framework (DRF) 中可以添加YAMLRenderer，其預設值始終是JSONRenderer。因為資料需要精確且快速。

結論：一句話總結

「機器之間的對話 (API) 交給JSON，人與機器之間的對話 (設定) 交給YAML。」

推薦閱讀：