主な要因は次のとおりです。
- クライアントにはどのような機能がありますか？（たとえば、パフォーマンス上の理由からほとんどのXMLパーサーを除外せずに、シェルフからXMLパーサーを選択できますか？その場でパケットを圧縮できますか？）
- データの複雑さはどのくらいですか（「フラット」または深く構造化されていますか？）
- 高周波アップデートが必要ですか？部分的な更新？
私の経験では：
のインターフェイスを備えた単純なテキストプロトコル（DSLとして分類されます）
string RunCommand(string commandAndParams)
// e.g. RunCommand("version") returns "1.23"
デバッグ、ロギングとトレース、プロトコルの拡張など、多くの側面が簡単になります。デバイス用のシンプルな端末/コンソールを持つことは、問題の追跡、テストの実行などに非常に役立ちます。
他の形式の参照点として、制限について詳しく説明しましょう。
- クライアントはマイクロパーサーを実行する必要があります。思ったほど複雑ではありませんが（私の「マイクロパーサーライブラリ」のコアは、合計約200行のコードを持つ10個の関数です）、基本的な文字列処理が可能であるはずです。
- ひどく書かれたパーサーは大きな攻撃対象領域です。デバイスがクリティカル/センシティブである場合、または敵対的な環境で実行されることが予想される場合、実装には細心の注意が必要です。（これは他のプロトコルにも当てはまりますが、すぐにハッキングされたテキストパーサーは間違えやすいです）
- オーバーヘッド。混合テキスト/バイナリプロトコル、またはbase64（37％のオーバーヘッドがある）によって制限できます。
- レイテンシー。通常のネットワーク遅延では、多くの小さなコマンドを発行する必要はありません。リクエストをバッチ処理する何らかの方法とそのリターンが役立ちます。
- エンコーディング。ASCIIで表現できない文字列を転送する必要があり、両端でUTF-8のようなものを使用できない場合、テキストベースのプロトコルの利点は急速に低下します。
バイナリプロトコルを使用するのは、デバイスから要求された場合、デバイスの処理能力がめちゃくちゃ低い場合（たとえば、256バイトのRAMを搭載したUSBコントローラー）、または帯域幅が大幅に制限されている場合のみです。私が使用したプロトコルのほとんどはそれを使用しており、それは苦痛です。
Google protBufは、バイナリプロトコルをいくらか簡単にするためのアプローチです。ライブラリを両端で実行でき、フォーマットを定義するのに十分な自由がある場合は、良い選択です。
CSVは、大量のデータを簡単に解析できる形式にパックする方法であるため、テキスト形式の拡張です。ただし、構造は非常に限られています。データが適切であることがわかっている場合にのみ、これを使用します。
XML / YAML / ...処理能力が問題ではなく、帯域幅が問題ではないか、オンザフライで圧縮でき、データの構造が非常に複雑な場合にのみ使用します。JSONは、オーバーヘッドとパーサーの要件が少し軽いようですが、良い妥協案かもしれません。