開發者工具 · JSON 格式化程式和驗證程序
JSON 如何取代 XML 作為 Web API 的預設格式
· 背景
json 標準 驗證
二十年前 XML 是系統之間發送的任何內容的假定格式。這篇文章追蹤了 JSON 如何在 Web API 中取代它、每種格式的設計目的以及為什麼 XML 仍然主導著某些領域。
還剩一個 SOAP 端點
還剩下一個 SOAP 端點 — 一種在程式碼庫中使用 XML 的集成，而其他所有內容都使用 JSON ，以及我們如何到達這裡的問題。這種對比經常出現在客戶端程式碼中：一條路徑管理信封、命名空間和產生的類型，而較新的端點透過輕量級 HTTP 庫交換普通物件。這一觀察描述了當地的建築，而不是普遍的年表。
格式化程式僅處理 JSON；跨格式轉換屬於單獨的語法轉換器面板。 JSON 的流行並不會讓 XML 過時，本地漂亮列印也不會驗證 API 合約。本文將歷史採用與此路線上實施的較窄行為區分開來。關於決定性日期、原因或整個市場替代的不受支持的歷史說法被故意省略或糾正，而不是從當前的違約中推斷出來。
XML 的用途
XML 的建置目的 — 具有混合內容、命名空間、模式和轉換管道的檔案。元素可以包含文字和子標記，屬性可以攜帶元資料，命名空間限定的名稱讓詞彙表共存。 XML Schema、XPath 和 XSLT 等技術支援跨以檔案為中心的工作流程的驗證、查詢和轉換。
當有效負載是出版品、簽署的業務檔案或可擴展的產業訊息時，這些功能並不是無緣無故的。它們確實強加了比簡單的物件和陣列交換所需的更多概念。因此，比較等效範例應考慮契約，而不僅僅是字元數： XML 和 JSON 公開不同的建模工具，並兩種語法都不會自動提供正確的領域語義。
瀏覽器本身可以做什麼
瀏覽器本身可以做什麼 — XMLHttpRequest 可以檢索任一文字格式，而瀏覽器提供 XML DOM 解析。早期的 JavaScript 程式碼有時會評估類似 JSON 的文字，當輸入不受信任時，這是一種不安全的做法；標準化的 `JSON.parse` 後來提供了專用的解析器。解析後的 JSON 自然會對應到 JavaScript 陣列、物件、字串、數字、布林值和 null。
這種映射減少了許多瀏覽器應用程式的儀式，但這並不能證明瀏覽器無法處理 XML 或僅由一個 API 決定採用。 XML DOM 保留元素、屬性和命名空間，而不是自動變成普通物件。關於因果關係的歷史主張需要超出實現便利性的來源，因此此處省略或糾正了不受支持的版本。
轉折點 — 公共 Web API 提供 JSON 和 XML，然後僅提供 JSON，並 REST 取代了大多數新服務的 SOAP
轉折點 — 許多公共 Web API 與 XML 一起公開 JSON，並許多後來的服務選擇 JSON 作為其主要表示形式。輕量級 HTTP 樣式對於應用程式 API 也變得很常見，而 SOAP 仍然保留在已建立的生態系統中。確切的市場份額、先行者和日期因來源而異，無法從此格式化程式儲存庫中確定。
因此，不受支持的歷史主張被省略或糾正，而不是轉換成一個整潔的單一原因故事。可防禦的機制是互通性壓力：一旦團隊圍繞某種格式進行標準化，客戶端程式庫、檔案、工具和鄰近服務就會強化該格式。此回饋可以解釋本機預設值，而無需宣告 XML 消失或每個 REST API 使用 JSON。
轉換成本
切換的成本 — JSON 在屬性和子元素之間沒有原生區別，沒有混合內容模型，也沒有註解語法。基本 JSON 語法也沒有定義應用程式模式。需要合約的團隊添加單獨的系統，例如 JSON Schema 或 OpenAPI，每個系統都有自己的詞彙表、工具和版本控制決策。
轉換可能會遺失資訊。重複的 XML 元素可能會變成數組，命名空間限定的名稱需要表示，並與標記交錯的文字並不總是乾淨地變成簡單的物件。更簡單的有效負載語法將一些複雜性轉移到外部契約或約定；它不會使驗證、演進和檔案變得不必要。
XML 仍然獲勝
XML 仍然獲勝－發布工作流程受益於混合內容和既定的文件詞彙表，而 Office 格式則打包 XML 部分來表示豐富的文件。成熟的金融和企業訊息傳遞標準可能依賴命名空間、模式、簽名或長期工具投資。替換語法需要生態系統協調，而不僅僅是更短的範例有效負載。
XML 也很有用。 JSON 可以透過附加約定為這些領域提供服務，就像 XML 可以為普通 API 提供服務一樣，但遷移價值必須超過合約和工具成本。面向瀏覽器的服務的受歡迎程度並不能證明每個表示問題的優越性，並糾正或省略了不受支援的總位移的主張。
這不包括什麼
這不包括 - 二元替代品，例如 Protocol Buffers 和 MessagePack，它們在不同的條款上競爭。它們的線路尺寸、模式要求、流行為和工具需要單獨評估。這也不能比較超媒體約定、傳輸協定或 API 風格； SOAP 與 REST 的比較不僅僅是 XML 與 JSON 的比較，而且任一表示形式都可以透過 HTTP 傳輸。
這也不是 API 採用的定量歷史記錄。關於日期、百分比、首次實施或全行業原因的精確陳述不受列出的存儲庫證據的支持，因此它們被省略或更正。相反，本文解釋了可觀察的格式功能和合理的工程後果，但沒有將這些後果作為完整歷史敘述的證據。
重點：JSON 贏得簡單性，而不是完整性
重點：JSON 透過緊湊的資料模型、主流語言的直接支援和廣泛的周邊工具成為許多 Web API 的常見預設值，而不是因為它包含 XML 提供的所有功能。 XML 在檔案結構、命名空間、轉換或已建立的模式為中心的情況下仍然適用。格式選擇遵循合約和生態系統，而不是通用排名。
ToolAcre 透過在此路徑上解析、驗證和漂亮列印 JSON 來反映 JSON 的窄模型；它不驗證 API 語意或使 XML 過時。僅當定義的映射保留所需資訊時才使用跨格式轉換。對歷史同樣要小心：關於單一轉折點或完全替代的不受支持的主張被忽略或糾正，留下可以辯護的機制和當前行為。