開発者ツール · JSON フォーマッタおよびバリデータ
Web API のデフォルト形式として JSON が XML に置き換わった方法
· 背景
json 規格 検証
20 年前、XML は、システム間で送信されるすべての形式として想定されていました。この投稿では、Web API で JSON がどのように置き換えられたのか、それぞれの形式が何のために設計されたのか、そして XML が依然として一部のドメインを支配している理由を追跡します。
SOAP エンドポイントが 1 つ残っています
残りの SOAP エンドポイントは 1 つです。他のすべてが JSON を話すコードベース内で XML を話す統合と、どうやってここにたどり着いたかという問題です。この対照はクライアント コードによく現れます。1 つのパスがエンベロープ、名前空間、生成された型を管理するのに対し、新しいエンドポイントは軽量の HTTP ライブラリを通じて通常のオブジェクトを交換します。この観察は、普遍的な年表ではなく、ローカルなアーキテクチャを説明しています。
フォーマッタは JSON のみを処理します。クロスフォーマット変換は、別の構文コンバーター パネルに属します。 JSON の人気によって XML が廃止されることはありません。また、ローカルのプリティプリントが API コントラクトを検証することもありません。この記事では、歴史的な採用と、このルートで実装されたより狭い動作を区別します。決定的な日付、原因、または市場全体の置き換えに関する裏付けのない過去の主張は、現在のデフォルトから推測するのではなく、意図的に省略または修正されます。
XML の目的
XML の目的 - コンテンツ、名前空間、スキーマ、変換パイプラインが混在するドキュメント。要素にはテキストと子マークアップの両方を含めることができ、属性にはメタデータを含めることができ、名前空間で修飾された名前により語彙を共存させることができます。 XML スキーマ、XPath、XSLT などのテクノロジは、ドキュメント中心のワークフロー全体での検証、クエリ、変換をサポートします。
ペイロードが出版物、署名されたビジネス文書、または拡張可能な業界メッセージである場合、これらの機能は無償ではありません。これらは、単純なオブジェクトと配列の交換に必要な概念よりも多くの概念を強制します。したがって、同等の例を比較する場合は、単なる文字数ではなく規約を考慮する必要があります。XML と JSON は異なるモデリング ツールを公開しており、どちらの構文も正しいドメイン セマンティクスを自動的に提供しません。
ブラウザーがネイティブに実行できること
ブラウザーがネイティブに実行できること — XMLHttpRequest はいずれかのテキスト形式を取得でき、ブラウザーは XML DOM 解析を提供しました。初期の JavaScript コードは JSON のようなテキストを評価することがありましたが、これは入力が信頼できない場合に危険な行為でした。標準化された `JSON.parse` は、後に専用のパーサーを提供しました。解析された JSON は、JavaScript の配列、オブジェクト、文字列、数値、ブール値、および null に自然にマップされます。
このマッピングにより、多くのブラウザ アプリケーションの儀式が軽減されますが、ブラウザが XML を処理できなかったという証拠でも、1 つの API だけで採用が決定されたという証拠でもありません。 XML DOM は、自動的にプレーン オブジェクトになるのではなく、要素、属性、名前空間を保持します。因果関係に関する歴史的な主張には、実装の利便性を超えたソースが必要であるため、サポートされていないバージョンはここで省略または修正されます。
転換点 — パブリック Web API は、XML と並行して JSON を提供し、その後 JSON のみを提供し、ほとんどの新しいサービスで SOAP を REST に置き換えました。
転換点 — 多くのパブリック Web API は XML とともに JSON を公開し、その後の多くのサービスは主な表現として JSON を選択しました。 SOAP が確立されたエコシステムにとどまる一方で、軽量の HTTP スタイルもアプリケーション API で一般的になりました。正確な市場シェア、先行者、日付はソースによって異なり、このフォーマッタ リポジトリから確立することはできません。
したがって、裏付けのない歴史的主張は、きちんとした単一原因の物語に変換されるのではなく、省略または修正されます。防御可能なメカニズムは相互運用性への圧力です。チームがフォーマットを標準化すると、クライアント ライブラリ、ドキュメント、ツール、および隣接するサービスがそのフォーマットを強化します。このフィードバックは、XML が消えたとか、すべての REST API が JSON を使用しているなどと主張することなく、ローカルのデフォルトを説明できます。
スイッチのコスト
切り替えのコスト — JSON には、属性と子要素間のネイティブな区別がなく、混合コンテンツ モデルやコメント構文もありません。基本 JSON 文法もアプリケーション スキーマを定義しません。契約が必要なチームは、JSON スキーマや OpenAPI などの個別のシステムを追加し、それぞれに独自のボキャブラリー、ツール、バージョン管理の決定が含まれます。
したがって、マッピングが明示的に設計されていない限り、変換によって情報が失われる可能性があります。繰り返される XML 要素は配列になる可能性があり、名前空間で修飾された名前には表現が必要であり、マークアップが組み込まれたテキストは必ずしもきれいに単純なオブジェクトになるとは限りません。ペイロード構文が簡素化されたことで、一部の複雑さが外部の契約または規則に移されました。検証、進化、文書化が不要になるわけではありません。
XML が依然として勝つところ
XML が依然として優れている場合 — 公開ワークフローは混合コンテンツと確立されたドキュメント語彙から恩恵を受ける一方、オフィス形式は豊富なドキュメントを表現するために XML パーツをパッケージ化します。成熟した金融およびエンタープライズ メッセージング標準は、名前空間、スキーマ、署名、または長期にわたるツールへの投資に依存している場合があります。構文を置き換えるには、サンプル ペイロードを短くするだけでなく、エコシステムの調整が必要になります。
XML は、変換とパスベースのクエリがワークフローの中心である場合にも役立ちます。 JSON は、XML が通常の API を提供できるのと同様に、追加の規則を使用してこれらのドメインにサービスを提供できますが、移行の価値は契約とツールのコストを超える必要があります。ブラウザ向けサービスの人気は、すべての表現問題に対する優位性の証拠ではないため、総変位に関するサポートされていない主張は修正または省略されます。
これでカバーされない内容
これでカバーされないもの – プロトコル バッファーやメッセージパックなど、異なる条件で競合するバイナリの代替手段。ワイヤ サイズ、スキーマ要件、ストリーミング動作、およびツールについては、個別に評価する必要があります。また、これはハイパーメディアの規則、トランスポート プロトコル、または API スタイルを比較するものでもありません。 SOAP と REST は、単純に XML と JSON という関係ではなく、どちらの表現も HTTP 経由で送信できます。
これは、API 導入に関する情報源に基づいた定量的な履歴でもありません。日付、割合、最初の実装、または業界全体の原因に関する正確な記述は、リストされたリポジトリの証拠によって裏付けられていないため、省略または修正されています。この記事では、完全な歴史的物語の証拠としてそれらの結果を提示することなく、観察可能なフォーマット機能と妥当なエンジニアリング結果について説明します。
要点: JSON は完全性ではなくシンプルさで勝った
要点: JSON は、XML が提供するすべての機能が含まれているからではなく、コンパクトなデータ モデル、主流言語での直接サポート、および広範な周辺ツールを通じて、多くの Web API の共通のデフォルトになりました。 XML は、ドキュメント構造、名前空間、変換、または確立されたスキーマが中心となる場合に引き続き適切です。形式の選択は、普遍的なランキングではなく、契約とエコシステムに従います。
ToolAcre は、このルート上で JSON を解析、検証し、整形して出力することにより、JSON の狭いモデルを反映します。 API セマンティクスを保証したり、XML を廃止したりするものではありません。クロスフォーマット変換は、定義されたマッピングに必要な情報が保持されている場合にのみ使用してください。歴史についても同様に注意してください。特異な転換点や完全な置き換えについての裏付けのない主張は省略または修正され、防御可能なメカニズムと現在の動作が残されます。