sockets - Webソケットを介して通信するためのプロトコル

Question

大規模で複雑なサーバー側コンポーネントを使用して、プロジェクトのクライアント側で作業しています。クライアントは、他のコンテキストの中でもモバイルアプリとしてデプロイされます。

クライアント/サーバー通信の場合、2つの相反する見方があります。

• RESTを使用する
• Webソケットを使用する

個人的には、結果として得られるAPIがよく考えられ、理解可能で拡張可能である限り、どちらのアプローチを採用してもかまいません。

複雑なC++ベースのアプリケーションで以前にTCPソケットを使用した経験から、独自の構文/プロトコルはすぐに一貫性がなくなり、混乱し、管理が困難になる可能性があることを私は知っています。

Webソケットを使用したクライアント/サーバー通信用のRESTやSOAPなどの汎用スタイルまたはプロトコルはありますか？独自のクライアント/サーバー通信スキーム/プロトコルを設計するためのガイドラインまたはベストプラクティスはありますか？

Answer 1

WAMPを見たことがありますか？

上記のページから：

WebSocketプロトコルはすでに最新のブラウザーに組み込まれており、双方向の低遅延のメッセージベースの通信を提供します。ただし、そのため、WebSocketは非常に低レベルであり、生のメッセージングのみを提供します。

最近のWebアプリケーションでは、パブリッシュ＆サブスクライブやリモートプロシージャコールなどの高レベルのメッセージングパターンが必要になることがよくあります。

ここで、WebSocketアプリケーションメッセージングプロトコル（WAMP）が登場します。WAMPは、RPCとPubSubの高レベルのメッセージングパターンをWebSocketに1つのプロトコル内で追加します。

技術的には、WAMPは公式に登録されたWebSocketサブプロトコル（WebSocket上で実行）であり、メッセージのシリアル化形式としてJSONを使用します。

WAMPはオープンなWeb標準を採用しており、使いやすく、実装も簡単になるように設計されています。

Answer 2

少しも意図せずに、ジェシー、私はいくつかの調査の後に私自身の質問に答えるつもりです。

私はRESTに相当するものに出くわしませんでした。現在の傾向は、JSONを使用してオブジェクトを送受信することです。これはJavaScript指向の世界では理にかなっているようで、メッセージは受信時にデータをすぐに更新できます。

例えば：

• https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications
• http://blog.new-bamboo.co.uk/2010/2/10/json-event-based-convention-websockets

私はこれらの方針に沿って独自のプロトコルを書くことに挑戦しました。しかし、私が出会った中で最も完全に定義されたプロトコルはJSON-RPCです。このプロトコルのもう1つの利点は、ソケットとHTTPが混在するアプリケーションで作成する場合に、HTTPとWebSocketで同じメッセージングシステムを使用できることです。

私が遭遇した別のアプローチは、既存のメッセージングプロトコルをWebSocketに「移植」することでした（JSONを使用しているかどうかに関係なく）。したがって、たとえば、XML-RPC（JSON-RPCのベース）は、ソケットで使用するためにかなり簡単に再実装できます。実際、SOAPはソケットを介して再実装することもできます。

上記のリンクの1つはSTOMPでしたが、私が出くわした素敵で小さなプロトコルです。それも移植することができます-そして確かに持っています。

Answer 3

Javaを想定すると、http、websocket、さらにはspdyなどのプロトコルの上にあるメッセージングのメカニズムとしてCometd（www.cometd.org）が好きです。そのようなものの魅力は、そのAPIにコーディングし、特定のクライアント/サーバーの組み合わせに最適な基盤となるプロトコルをシームレスに分類することです。古いIEを使用している場合は、通常の通常のhttpにフォールバックしますが、新しいIEの場合は、WebSocketを選択する可能性があります。ChromeまたはFirefoxを使用している場合は、spdyを入手できます。また、spdyに基づくhttp / 2.0がリリースされると、cometdを更新して無料で入手できます。また、WebSocketに加えてより高度なプロトコルを使用すると、トンネルを通過して接続が失われた場合のメッセージ回復などの機能を利用できます。

個人的には、RESTとWebSocketが競合している、または反対しているとは思っていません。これらは異なる生き物です。RESTは、HTTPスタイルのステートレス環境とURLの規則をいじることから生まれたソリューションですが、websocketはhttpの代替プロトコルです。RESTを使用すると、TCP接続のウォーミングアップに関心がないため、スループットが向上しますが、WebSocketやspdyなどの潜在的に長寿命の接続では、この種のことがより一般的になります。パイプラインを使用したhttp/1.1はそのためのオプションですが、モバイルブラウザが実際にデフォルトで使用を開始するまで、サポートが不十分なため、その潜在能力を十分に発揮できていません。