Protobufは良いことです。c++開発者がクラスのシリアライゼーション/デシリアライゼーションを気にする必要がなく、高速で、.proto形式は非常に優れています。自動データ検証も可能です。しかし、メッセージは人間が読めるものではなく、最も重要なのは人間が作成できるものではありません。これは、リモートサーバーからの特定の刺激に対する応答をすばやくテストする必要がある場合の問題です。
私に思われるように、解決策は、protobufメッセージを作成し、それをいくつかのライブラリを介してjsonに変換し、これを送信します。同じライブラリを使用して、サーバーのprotobufにデシリアライズし、c ++に戻します。
メッセージの検証、.protoファイルからのクラスの自動生成、jsonの読みやすさの両方が得られたようです。確かに遅いですが、私の仕事では速度は必須ではありません。それでも、それは正気ですか?確かに、私はネットワーキングや記述されたアプローチから発生する可能性のある問題についてほとんど知識がありません。誰かに将来の問題があるかどうか教えてもらえますか?
パフォーマンスのオーバーヘッドを処理できる限り、ProtobufをJSONに変換したり、元に戻したりすることは完全に機能します。私はそのようなことをするプロジェクトに取り組み、JSONをReST呼び出しの優先フォーマットとして使用して、パフォーマンスを下げ、使いやすさを向上させました。基になるサービスが直接使用するProtobufに変換されたWebレイヤー。直接Protobufコンテンツタイプを含めたので、JSONエンコーディング/デコーディングをバイパスし、HTTP(S)経由でProtobufを使用できます。
特定の特権のある高性能クライアントは、同じサービスにProtobuf/RPCインターフェイスを実装したrawソケットインターフェイスにアクセスできます。
すべてうまくいきました。私は、どのクライアントもprotobufをJSONに変換したとは思いません-しかし、彼らはそれを行うことができたでしょう。スキーマが利用可能であり、移行またはデバッグに使用できた可能性があります。
編集:
@RobertHarveyが彼のコメントで観察しているように、protobufには「テキストフォーマッタ/パーサー」ライブラリがあり、ここで説明されています。 https://developers.google.com/protocol-buffers/docs/reference/cpp/google。 protobuf.text_format 。これにより、以下が提供されます。
人間が読めるテキストベースの形式でプロトコルメッセージを印刷および解析するためのユーティリティ
わかりやすくするために、これはprotobufワイヤープロトコルではありません(たぶん1つになる可能性があります!)。しかし、protobufメッセージをテキストとして処理するのに役立つツールキットです。これはおそらく、特にJSONを使用する必要がないことを意味します。 protobufメッセージをテキストとして表示し、編集して再エンコードするツールを作成できます。