舊版 XML 響應為 JSON：有利于檢查，但對代碼有风险

它可以處理一個結果，但會破壞兩個結果 - XML feed 看起來像一個整潔的 JSON 對象，直到第二個元素出現

具有一個結果的 XML 樣本將其子項對應到物件或字串；第二個兄弟將相同的屬性轉換為陣列。因此，當基數發生變化時，針對第一個轉換的樣本編寫的程式碼可能會失敗。 JSON 是觀察到的事件的投影，而不是模式感知合約。

ToolAcre 使映射可預測，但無法消除這種一對多的歧義。為了實現長期集成，請標準化 XSD 或檔案化合約中的已知收集路徑，並針對生產中實際使用的 XML 讀取器測試這兩個基數。

為什麼轉換非常適合閱讀 - 嵌套扁平化為熟悉的大括號，屬性作為鍵出現，並整個響應可立即掃描

轉換非常適合閱讀，因為巢狀元素變成熟悉的對象，重複的同級元素變成數組，屬性顯示為 `@` 鍵。無需在心裡匹配封口標籤即可快速掃描大信封。類型推斷可以保持關閉狀態，因此文字不會被默默地猜測為數字或布林值。

可讀視圖在事件分類期間特別有用，其中定位錯誤代碼或有效負載比保留作者標記更重要。將原始程式碼保留在 JSON 旁邊，因為投影可能不會保留應用程式程式碼所需的所有差異。

為什麼轉換後的形狀不穩定－重複元素只有重複才變成陣列、屬性前綴、出現或消失的文字節點

轉換後的形狀取決於出現次數、保留前綴以及元素是否具有屬性或子元素。純文字可以折疊為字串；當添加結構時，相同的文字會移動到 `#text` 下。 CDATA 出現在 `#cdata` 下，屬性使用 `@`。

這些轉換是記錄在案的約定，而不是不穩定的實施事故。只有當程式碼假設一個樣本定義了所有未來的 XML 形狀時，它們才會變得有風險。模式感知模型可以說明可重複性和可選性；通用解析器不能。

程式碼可能需要的東西會遺失－命名空間、元素順序、混合內容、CDATA 邊界和註釋

命名空間前綴保留在屬性名稱中，聲明保留為 `@xmlns:*`；他們沒有決定擴展名稱。 CDATA 仍在其特殊鍵下進行標記。評論、聲明和處理說明將被刪除。子元素周圍的混合文字被連接並失去相對位置。

元素順序無法安全地取代 XML 節點序列。如果檔案順序、混合散文或精確的 CDATA 邊界很重要，請使用 XML 樹或事件解析器，而不是此 JSON 形狀的視圖。

命名空間前綴和 CDATA 值保持可見，但排序和節點邊界可能會遺失

使用帶有命名空間前綴、一個正文子元素和兩個結果元素的信封形檔案。轉換顯示主體路徑，保留文字前綴並產生結果陣列。此範例示範了導航，但沒有宣告 WSDL、SOAP 錯誤或命名空間解析支援。

然後重複一個結果並觀察陣列消失。該對是回歸夾具應用程式程式碼所需的。 ToolAcre 可以揭示差異；它無法決定您的網域是否應始終將值包裝在陣列中。

工作範例：未宣告 SOAP 模式支援的信封形 XML 文件

當記錄映射、基數標準化並固定裝置覆蓋屬性、空值、混合內容和命名空間時，對於以資料為中心的 XML 來說，取決於轉換可能是合理的。將映射本身視為應用程式擁有的介面。

保持類型推斷明確。關閉它時，值是字串；打開它後，解析器啟發式選擇數字和布林值。穩定的映射不應在環境之間意外切換該選項。

這不包括什麼 - 用於產生類型化客戶端的 WSDL 和 XSD 工具，這是長期整合的可靠途徑

不包含 WSDL 或 XSD 工具。轉換器驗證格式正確的 XML，拒絕每個 DOCTYPE 和專案節點；它不會產生類型化客戶端、驗證序列或強制執行域方面。這些任務需要模式感知軟體。

DOCTYPE 拒絕也意味著某些遺留檔案將無法解析，即使它們的宣告是無害的。這是防止實體擴展的安全邊界，而不是底層服務回應格式錯誤的證據。

重點：轉換以理解，解析以實現 - 以及語法轉換器面板如何在幾秒鐘內為您提供可讀視圖

轉換理解；根據擁有的合約進行解析以實施。 JSON 視圖可以在幾秒鐘內顯示有效負載，而原始 XML 仍然是排序、基數和命名空間的證據。

語法轉換器對其投影和警告是誠實的。使用這種可見性來設計邊緣情況測試，而不是讓一個整潔的範例定義一個在下一個重複元素上中斷的整合。

一套耐用的固定裝置應包括零次、一次和多次出現的可重複元素；屬性和子級共享一個名稱；自閉合元件；混合文字；資料資料；和文字命名空間前綴。透過您實際部署的映射來執行這些裝置並斷言規範化域對象，而不是 ToolAcre 的格式化 JSON 文字。此方法使用轉換器來探索形狀，同時將生產行為與顯式解析器契約連結起來。