JSON vs XML：為什麼現代 API 都選擇 JSON

JSON 和 XML 都是結構化資料格式，但在實際開發中的使用體驗差異很大。XML 更明確、更冗長，在一些企業系統和歷史介面裡仍然常見。JSON 更精簡、更容易閱讀，也已經成為現代 REST API、Webhook、前端應用和日誌系統的預設格式。

這裡的問題不是 XML 是否已經過時。XML 在 SOAP API、文件格式、需要命名空間的系統、混合文字標記等情境中仍然有價值。更實際的問題是：為什麼大多數新 Web API 會選擇 JSON？開發者在傳送或儲存 JSON payload 前，又應該檢查什麼？

JSON 和 XML 對比

下面是同一份使用者資料的 XML 表示：

<user>
  <id>1</id>
  <name>張三</name>
  <email>[email protected]</email>
  <active>true</active>
</user>

對應的 JSON 表示是：

{
  "id": 1,
  "name": "張三",
  "email": "[email protected]",
  "active": true
}

JSON 更短，因為每個欄位名稱只出現一次。XML 中欄位名稱通常既要出現在起始標籤裡，也要出現在結束標籤裡。對於很小的 payload，這點差異不明顯；但對於大型 API 回應，它會影響可讀性、傳輸量和除錯速度。

JSON 天然對應物件、陣列、字串、數字、布林值和 null。這些型別和 JavaScript、TypeScript、Go、Python、Java、PHP 等語言裡的基礎資料結構都很容易互相轉換。

因此 JSON 很適合：

JSON 也很適合瀏覽器除錯。開發者可以從 Network 面板複製回應，格式化 payload，截取一小段資料重現問題，而不需要理解額外的標記模型。

XML 有一些 JSON 並不打算替代的能力，比如屬性、命名空間、Schema、註解、處理指令，以及文字和結構混合的內容。這些能力在文件型資料和成熟企業系統裡仍然有意義。

XML 常見於：

如果資料更像一份文件，XML 可能是合理選擇。如果資料更像物件、陣列或介面訊息，JSON 通常更簡單。

一個常見誤解是：看起來像 JavaScript 物件的內容，就一定是合法 JSON。實際上標準 JSON 比 JavaScript 物件字面量嚴格得多。

下面這段是合法 JavaScript，但不是合法 JSON：

{
  name: '張三',
  active: true,
}

標準 JSON 要求欄位名稱和字串都使用雙引號，而且不允許尾隨逗號：

{
  "name": "張三",
  "active": true
}

這個差別在 API 介面、資料庫 JSON 欄位、瀏覽器 JSON.parse() 中尤其重要。JSON5 和帶註解 JSON 可以用於本機設定，但在作為 API 資料傳送前，通常應該先轉換為標準 JSON。

當介面拒絕 JSON payload 時，原因經常很小：

例如下面這段看起來很清楚，但嚴格 JSON 解析會失敗：

{
  "limit": 20,
  "includeArchived": false,
}

最後一個逗號是非法的。嚴格解析器可能提示 Unexpected token }，看起來像是右大括號有問題，實際原因通常是前面的逗號。

如果資料要在系統之間交換、寫入 JSON 資料庫欄位、傳送到 REST API，或交給標準函式庫解析，優先使用 JSON。

如果外部系統明確要求 XML，或者需要命名空間、Schema、文件型結構，那麼繼續使用 XML。

如果檔案主要由人維護，並且使用方明確支援 JSON5 或 JSONC，可以使用帶註解 JSON。但它不應該被當成 API payload 的預設格式。