JSONからProtobufに移動します。その価値はありますか？
REST XMLまたはJSON（WCF）を提供できるwebservicesがあります。Protobufsを実装するアイデアに興味を持っています。なぜですか？
長所
- サーバーへの負荷が少ない。
- メッセージサイズが小さい-トラフィックが少ない。
- 後で切り替える方が簡単です。
短所
- 実装する必要がある
- デバッグのためにメッセージのトラブルシューティングや盗聴が困難になる。
- サーバーでGZipを有効にすると、JSONが多くのトラフィックを消費します
これに対するあなたの提案や経験は何ですか？
それらを実装することのビジネス価値はコストを超えていますか？
実装する場合は、サーバーだけでなくすべてのクライアントを変更する必要があります（両方の形式をサポートでき、必要に応じてクライアントのみを変更できます）。これには時間とテストが必要ですが、これは直接的なコストです。また、プロトコルバッファーを理解するのにかかる時間（特にフィールドを必須またはオプションにする理由）、およびprotobufコンパイラーをビルドプロセスに統合するのにかかる時間を過小評価しないでください。
値はそれを超えていますか？ 「帯域幅コストは収益のX％であり、それをサポートすることはできません」という選択に直面していますか？あるいは、「JSONをサポートするサーバーを追加するには、20,000ドルを費やす必要があります」とさえ言えますか？
差し迫ったビジネスニーズがない限り、「プロ」は実際にはプロではなく、時期尚早の最適化です。
私はprotobufを追加する前に、apiと誰かを維持しています（ "高速"だったため）。ペイロードが小さいためRTTが速くなる唯一のことは、gzipされたJSONで修正できます。
私にとって不愉快な部分は、（JSONと比較して）protobufを保守するための相対的な作業です。 Javaを使用しているため、JSONにJacksonオブジェクトマッピングを使用しています。応答に追加することは、POJOにフィールドを追加することを意味します。しかし、protobufの場合、.protoファイルを変更してから、シリアル化を更新し、プロトコルバッファーのデータをPOJOに移動したり、POJOにデータを移動したりする逆シリアル化ロジック。誰かがフィールドを追加し、プロトコルバッファーのシリアル化コードまたは逆シリアル化コードのいずれかを入力するのを忘れたリリースが発生したのは2回以上です。
クライアントがプロトコルバッファに対して実装されたので、回避することはほとんど不可能です。
あなたはおそらくこれから推測できますが、私のアドバイスはそれをしないことです。