JSONからProtobufに移行します。その価値はありますか？

XMLまたはJSON（WCF）を提供できるREST Webサービスがあります。Protobufsを実装するというアイデアをいじっています。どうして？

長所

1. サーバーの負荷が少ない。
2. メッセージサイズが小さい-トラフィックが少ない。
3. 後で切り替えるよりも、すぐに切り替える方が簡単です。

短所

1. 実装する必要がある
2. デバッグ用のメッセージのトラブルシューティング/スニッフィングが難しくなります。
3. サーバーでGZipを有効にすると、JSONは同じ量のトラフィックを消費します

これについてのあなたの提案や経験は何ですか？

それらを実装するビジネス上の価値はコストを上回りますか？

実装する場合は、サーバーだけでなく、すべてのクライアントを変更する必要があります（ただし、両方の形式をサポートし、必要に応じてクライアントのみを変更できます）。それには時間とテストが必要になりますが、これは直接的なコストです。また、プロトコルバッファを実際に理解するのにかかる時間（特にフィールドを必須またはオプションにする理由）、およびprotobufコンパイラをビルドプロセスに統合するのにかかる時間を過小評価しないでください。

では、値はそれを超えていますか？「帯域幅コストは収益のX％であり、それをサポートすることはできません」という選択肢に直面していますか？または、「JSONをサポートするサーバーを追加するために20,000ドルを費やす必要がありますか？」

差し迫ったビジネスニーズがない限り、「長所」は実際には長所ではなく、時期尚早な最適化です。

protobufを追加する前に、APIと誰かを保守しています（「高速」だったため）。より高速なのはペイロードが小さいためRTTであり、これはgzip圧縮されたJSONで修正できます。

私にとって嫌な部分は、プロトブフを維持するための相対的な作業です（JSONと比較して）。私はjavaを使用しているため、JSONにはJacksonオブジェクトマッピングを使用します。応答に追加するとは、フィールドをPOJOに追加することを意味します。しかし、protobufの場合は、.protoファイルを変更してから、データをプロトコルバッファーの内外に移動してPOJOに移動するシリアル化および非シリアル化ロジックを更新する必要があります。誰かがフィールドを追加し、プロトコルバッファのシリアル化または非シリアル化コードを入力するのを忘れたリリースが行われたことが何度もありました。

クライアントがプロトコルバッファに対して実装されたので、逃げることはほとんど不可能です。

あなたはおそらくこれから推測できるでしょう、私のアドバイスはそうしないことです。