内部サービス間の通信用に、強く型付けされた (読み取り - 事前定義されたスキーマを使用) データ交換形式を導入することを考えています。たとえば、Thrift や Cap'n Proto のようなものだと思います。
JSONのようなものよりもこれを使用することの（私にとっての）少なくとも2つの明らかな利点は、
JSON のようなものと比較して、このルートに進むことの実際的な欠点は何ですか?
コンテキスト - 私たちのシステムは、Python と Java で書かれたサービスで構成されています。また、将来的には他の言語で書かれる可能性もあり、HTTP エンドポイントを介して、サービスと rabbitmq などのメッセージ ブローカーとの間で通信します。
すべての厳密に型指定されたシステムと同様に、主な利点の 1 つは、間違いを犯した場合、プロセスの早い段階 (通常はコンパイル段階) で失敗することです。これは良いことです。
IMHO の 2 番目に大きな利点は、あなたがすでに言ったことです。フィールドと型がよく知られているため、コンパイラ、ライブラリ、および関連するコードは、期待されるデータを知っているため、より効率的な方法で記述/整理できます。
対照的に、(Avro のような) 厳密に型指定されていないシステムは、再コンパイルを必要とせずにはるかに高い柔軟性を可能にしますが、同じコインの反対側、つまり実行時にメッセージの内容に関するエラーが発生しやすいという欠点があります。
これは、あいまいに定義されたシステムが有効なドキュメント (XML など) の構文のみを定義し、ドキュメントの内容に関するメッセージ レベルのセマンティクスを上位層に任せているためです。厳密に型指定されたシステムは、コンパイル時に既に組み込まれているメッセージ レベルのセマンティクスに関する知識を持っています。したがって、特定のドキュメントまたはメッセージが整形式であるだけでなく、メッセージの内容に関して有効であるかどうかを簡単に検出/判断できます。曖昧に定義されたシステムで同じことを行う必要がある場合は、実行時に追加情報(XML スキーマなど) を提供し、それに対してドキュメントを検証する必要があります。
どのシステムを好むかは、ほとんどの場合、多かれ少なかれ好みの問題です。私は、対処しなければならないデータがどの程度変動するかという質問に基づいて決定を下します。厳密に型指定されたシステムを使用することが理にかなっている場合は、その方法を使用します。なぜなら、エラーや間違いについて早期に通知されることが非常に好きだからです。
ただし、非常に柔軟なデータ構造が必要な場合は、別の道を行く方が理にかなっています。厳密に型指定されたシステムの上に厳密に型指定されたスキーマを設計することは確かに可能ですが、それはいくぶん矛盾しており、過度に複雑でありながら過度に一般的なものになってしまうでしょう。
タイプされた
タイプタグ付きの受信メッセージは、すべてを読まなくても受信メッセージが何であるかを知ることができる限り、非常に自由です。もしそうなら、あなたはもはやメッセージの順序を気にしません。これは、メッセージの受信者が送信された内容を簡単に処理できるためです。したがって、取得したものをそのまま使用し、それぞれに適した処理を実行するアプリケーションを作成できます。
フォーマット
値とサイズの制約を定義できるスキーマ言語は非常に便利です。これは、メッセージの送信者が誤って無効なメッセージを送信できないことを意味します。さらに、受信者は受信メッセージがスキーマを満たしているかどうかを自動的に判断できます。これは、ネットワーク サービスを実装する上での真のボーナスです。メッセージの検証の大部分が自動的に行われます。
サイズの制約とは、スキーマ内の配列の長さを指定できることを意味し、生成されたコードはそれより長いまたは短い配列の処理を拒否します。値の制約により、「ベアリング」と呼ばれるメッセージ フィールドを想像してください。0 から 359 の間になるように制限したい場合があります。
これらはどちらも、インターフェイスが何であるかについて明確で明確なステートメントを作成し、それを自動的に適用することを可能にします。最近、いくつかのネットワーク インターフェイス データの検証が不適切に実装されているというセキュリティ バグがいくつありますか...
オプション
このすべてを行うシリアル化標準の 1 つが ASN.1 です。私が使用したツールは、ASN.1 スキーマを使用してシリアル化および逆シリアル化するコードを生成し、値とサイズの制約が満たされていることを自動的にチェックし、受信メッセージの種類を通知します。ASN.1 のツールはかなり古く、更新が必要です。更新された場合、バイナリ形式とテキスト ワイヤ形式の両方が利用可能で、あらゆる目的に最適です。
現在は JSON スキーマもあり、型、値、およびサイズの制約があるようです。これはあなたが探しているものかもしれません。
私は、Google Protocol Buffers がタイプのタグ付けをうまく行っておらず、値とサイズの制約を行っていないことを確信しています。次の行に沿って GPB スキーマのコメントを見てきました。
// 10 を超えてはなりません。
それがスキーマに書き込まれているものである場合、スキーマ言語は間違いなく不十分です...
Thriftについてはよくわかりません。値の制約があるかどうかもわかりません（間違っている場合は誰か訂正してください！）。
短所
何も考えられない！開発者をいらいらさせる可能性があります。彼らが良いと思ったコードが、ジャンク メッセージを生成していることがすぐに明らかになり、それが彼らをひどく悩ませています...