従来の XML の JSON としての応答: 検査には適していますが、コードには危険です

1 つの結果では機能しましたが、2 つの結果では機能しませんでした。XML フィードは、2 番目の要素が表示されるまでは整然とした JSON オブジェクトのように見えました。

1 つの結果を持つ XML サンプルは、その子をオブジェクトまたは文字列にマップします。 2 番目の兄弟は同じプロパティを配列に変換します。したがって、最初に変換されたサンプルに対して記述されたコードは、カーディナリティが変更されると失敗する可能性があります。 JSON は、観察された出来事の投影であり、スキーマを意識した契約ではありません。

ToolAcre はマッピングを予測可能にしますが、この 1 対多のあいまいさを取り除くことはできません。長期的な統合の場合は、XSD または文書化されたコントラクトからの既知のコレクション パスを正規化し、運用環境で実際に使用される XML リーダーに対して両方のカーディナリティをテストします。

変換が読み取りに優れている理由 — ネストは使い慣れた中括弧に平坦化され、属性はキーとして表示され、応答全体は一度にスキャン可能です

変換は、ネストされた要素が見慣れたオブジェクトになり、繰り返される兄弟が配列になり、属性が `@` キーとして表示されるため、読み取りに優れています。大きな封筒は、終了タグを頭の中で照合しなくても、すばやくスキャンできます。型推論はオフのままにすることができるので、テキストが暗黙的に数値やブール値に推測されることはありません。

読み取り可能なビューは、作成者のマークアップを保持することよりも、エラー コードやペイロードを見つけることが重要なインシデントの優先順位付けの際に特に役立ちます。プロジェクションではアプリケーション コードに必要なすべての区別が保持されない可能性があるため、ソースを JSON の横に置いてください。

変換された形状が不安定な理由 — 繰り返された場合にのみ配列になる繰り返し要素、属性プレフィックス、表示または消失するテキスト ノード

変換された形状は、出現回数、予約されたプレフィックス、および要素に属性または子があるかどうかによって異なります。プレーンテキストは文字列に折りたたむことができます。構造が追加されると、同じテキストが `#text` の下に移動します。 CDATA は `#cdata` の下に表示され、属性は `@` を使用します。

これらの移行は文書化された規約で​​あり、不安定な実装上の事故ではありません。コードが将来のすべての XML 形状を 1 つのサンプルで定義すると想定している場合にのみ、危険になります。スキーマ認識モデルは、再現性とオプション性を明示できます。汎用パーサーではできません。

コードで必要になる可能性があるもの - 名前空間、要素の順序、混合コンテンツ、CDATA 境界、コメント

名前空間の接頭辞はプロパティ名に残り、宣言は `@xmlns:*` のままになります。それらは拡張された名前には解決されません。 CDATA は特別なキーの下でマークされたままになります。コメント、宣言、および処理命令は削除されます。子要素の周囲に混在したテキストが結合され、相対的な位置が失われます。

異なる名前のプロパティ間の要素の順序は、オブジェクトへの投影後の XML ノード シーケンスの安全な置き換えにはなりません。ドキュメントの順序、散文の混合、または正確な CDATA 境界が重要な場合は、この JSON 型のビューではなく、XML ツリーまたはイベント パーサーを使用してください。

名前空間のプレフィックスと CDATA 値は表示されたままですが、順序とノードの境界は失われる可能性があります

名前空間プレフィックス、1 つの本体子要素、および 2 つの結果要素を持つ封筒型のドキュメントを使用します。変換により本文のパスが明らかになり、リテラルの接頭辞が保持され、結果の配列が生成されます。この例では、WSDL、SOAP 障害、または名前空間解決のサポートを要求しないナビゲーションを示します。

次に、1 つの結果で繰り返し、配列が消えるのを観察します。このペアは、アプリケーション コードに必要な回帰フィクスチャです。 ToolAcre は違いを明らかにすることができます。ドメインが値を常に配列でラップする必要があるかどうかを決定することはできません。

動作する例: SOAP スキーマのサポートを主張しない封筒型の XML ドキュメント

変換に依存することは、マッピングが文書化され、カーディナリティが正規化され、フィクスチャが属性、空の値、混合コンテンツ、および名前空間をカバーする場合、データ中心の XML にとって合理的である可能性があります。マッピング自体をアプリケーションが所有するインターフェイスとして扱います。

型推論を明示的に保ちます。オフにすると、値は文字列になります。これをオンにすると、パーサーのヒューリスティックによって数値とブール値が選択されます。安定したマッピングでは、環境間でそのオプションが誤って切り替わることはありません。

これでカバーされないもの — 型指定されたクライアントを生成するための WSDL および XSD ツール。これは、長期にわたる統合のための堅牢なルートです。

WSDL または XSD ツールは含まれません。コンバータは、整形式の XML を検証し、すべての DOCTYPE とプロジェクト ノードを拒否します。型付きクライアントの生成、シーケンスの検証、ドメイン ファセットの強制は行いません。これらのタスクにはスキーマ対応ソフトウェアが必要です。

DOCTYPE の拒否は、宣言が無害であっても一部のレガシー ドキュメントが解析されないことも意味します。これはエンティティの拡張を妨げるセキュリティ境界であり、基礎となるサービスの応答が不正であるという証拠ではありません。

要点: 理解するために変換し、実装するために解析する — および構文コンバーター パネルが数秒で読みやすいビューを提供する方法

変換して理解する。所有するコントラクトに対して解析して実装します。 JSON ビューは数秒でペイロードを明らかにできますが、元の XML は順序、カーディナリティ、名前空間の証拠として残ります。

構文コンバーターは、その予測と警告について誠実です。 1 つのきちんとしたサンプルで次の繰り返される要素で中断される統合を定義するのではなく、その可視性を利用してエッジケースのテストを設計します。

耐久性のあるフィクスチャ セットには、反復可能な要素が 0、1、および複数個含まれている必要があります。名前を共有する属性と子。自己終了要素。混合テキスト。 CDATA;そしてリテラルの名前空間プレフィックス。実際にデプロイするマッピングを通じてこれらのフィクスチャを実行し、ToolAcre の書式設定された JSON テキストではなく、正規化されたドメイン オブジェクトをアサートします。このアプローチでは、コンバータを使用してシェイプを探索しながら、生成動作を明示的なパーサー コントラクトに関連付けたままにします。