REST APIを置き換えるWebsocket API？

主な機能がWebSocketまたはロングポーリングを介してリアルタイムで動作するアプリケーションがあります。

ただし、サイトのほとんどはRESTfulな方法で記述されており、将来のアプリケーションや他のクライアントにとっては便利です。ただし、RESTから離れて、すべてのサイト機能のWebSocket APIへの移行を考えています。これにより、リアルタイム機能をサイトのすべての部分に統合しやすくなります。これにより、アプリケーションやモバイルクライアントの構築が難しくなりますか？

一部の人々はすでにこのようなことをしていることがわかりました：SocketStream

ここでの他の回答にメリットがないと言うのは言うまでもなく、それらはいくつかの良い点を示します。ただし、一般的なコンセンサスに反して、リアルタイム機能だけでなくWebSocketに移行することは非常に魅力的であることに同意します。

私はアプリをRESTfulアーキテクチャからWebSocketを介してより多くのRPCスタイルに移行することを真剣に検討しています。これは「おもちゃのアプリ」ではなく、リアルタイムの機能だけを話しているわけではないので、予約は必要です。しかし、私はこの経路を進むことで多くの利点を見出し、それが例外的な解決策になることが判明する可能性があると感じています。

私の計画は、DNode、SocketIO、およびバックボーンを使用することです。これらのツールを使用すると、RPCスタイルの関数を呼び出すだけで、バックボーンモデルとコレクションをクライアントとサーバーの間でやり取りできます。RESTエンドポイントの管理、オブジェクトのシリアライズ/デシリアライズなどは不要です。私はまだソケットストリームを扱っていませんが、チェックする価値があるようです。

これが良い解決策であると断定できるまでにはまだ長い道のりがあり、すべてのアプリケーションに最適な解決策ではないことは確かですが、この組み合わせは非常に強力であると確信しています。リソースをキャッシュする機能を失うなど、いくつかの欠点があることを認めます。しかし、私は利点がそれらを上回ると感じています。

このタイプのソリューションの探索の進捗状況に興味があります。githubの実験がある場合は、私にそれらを教えてください。まだありませんが、お早めに。

以下は、私が収集している「後で読む」リンクのリストです。私はそれらの多くをスキミングしただけなので、それらがすべて価値があることを保証することはできません。しかし、うまくいけば、いくつかは助けるでしょう。

ExpressでSocket.IOを使用するための素晴らしいチュートリアル。高速セッションをsocket.ioに公開し、認証されたユーザーごとに異なる部屋を持つ方法について説明します。

• http://www.danielbaulig.de/socket-ioexpress/

認証、Joyentホスティングなどを使用したnode.js / socket.io / backbone.js / express / connect / jade / redisのチュートリアル：

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-contin-authentication-profiles-ponies-and-a-meaner-socket-io/

Backbone.jsでPusherを使用するためのチュートリアル（Railsを使用）：

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

クライアントにbackbone.jsを使用し、サーバーにexpress、socket.io、dnodeを使用してnode.jsでアプリケーションをビルドします。

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-contin-authentication-profiles-ponies-and-a-meaner-socket-io/

DNodeでのバックボーンの使用：

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP RESTとWebSocketは大きく異なります。HTTPはステートレスなので、Webサーバーは何も知る必要がなく、Webブラウザーとプロキシでキャッシュを取得します。WebSocketを使用する場合、サーバーはステートフルになり、サーバー上のクライアントに接続する必要があります。

要求/応答通信とプッシュ

サーバーからクライアントにデータをプッシュする必要がある場合にのみWebSocketを使用します。その通信パターンはHTTPに含まれていません（回避策のみ）。PUSHは、他のクライアントによって作成されたイベントを、接続されている他のクライアントが利用できるようにする必要がある場合などに役立ちます。または、Webサイトが何かを監視している場合、サーバーは常にクライアントにデータをプッシュします。

サーバーからデータをプッシュする必要がない場合は、通常、ステートレスHTTP RESTサーバーを使用する方が簡単です。HTTPは単純なRequest-Reply通信パターンを使用します。

すべてのサイト機能をWebSocket APIに移行することを考えています

いいえ、できません。両方のモデルをサポートしていても害はありません。特にサーバーがリアルタイムの通知を送信する場合は、一方向通信/単純な要求にはRESTを使用し、双方向通信にはWebSocketを使用します。

WebSocketはRESTful HTTPよりも効率的なプロトコルですが、以下の領域ではWebSocket よりもRESTful HTTPスコアが高くなっています。

1. 作成/更新/削除リソースは、HTTPに対して適切に定義されています。WebSocketの場合、これらの操作を低レベルで実装する必要があります。

2. WebSocket接続は、HTTP接続が水平に拡大するのに対して、単一サーバーでは垂直に拡大します。WebSocket水平スケーリングには、非標準ベースの独自のソリューションがいくつかあります。

3. HTTPには、キャッシング、ルーティング、多重化、gzip圧縮などの優れた機能がたくさんあります。Websocketを選択した場合、これらはWebsocketの上に構築する必要があります。

4. 検索エンジン最適化は、HTTP URLに対して適切に機能します。

5. すべてのプロキシ、DNS、ファイアウォールはまだWebSocketトラフィックを完全には認識していません。それらはポート80を許可しますが、最初にそれをスヌーピングすることによってトラフィックを制限するかもしれません。

6. WebSocketによるセキュリティは、オールオアナッシングアプローチです。

詳細については、この記事をご覧ください。

TCP（WebSockets）をメインのWebコンテンツ配信戦略として使用できる唯一の問題は、TCPを使用してWebサイトのアーキテクチャとインフラストラクチャを設計する方法に関する資料がほとんどないことです。

したがって、他の人の過ちから学ぶことはできず、開発は遅くなります。また、「試行錯誤した」戦略でもありません。

もちろん、HTTPのすべての利点も失われます（ステートレスであること、およびキャッシングがより大きな利点です）。

HTTPは、Webコンテンツを提供するために設計されたTCPの抽象概念であることに注意してください。

また、SEOと検索エンジンはWebSocketを実行しないことを忘れないでください。だからあなたはSEOを忘れることができます。

個人的にはリスクが高すぎるため、これはお勧めしません。

Webサイトの提供にWSを使用せず、Webアプリケーションの提供に使用する

しかし、もしあなたがおもちゃや個人のウェブサイトを持っているなら、ぜひそれのために行ってください。それを試してください、最先端です。企業や会社にとって、これを行うリスクを正当化することはできません。

私は少しのレッスンを学びました（難しい方法）。私は、Ubuntu AWS EC2クラウドサービス（強力なGPUを使用）で実行される数値計算アプリケーションを作成しました。その進行状況をリアルタイムで監視するためだけにフロントエンドを作成したいと考えていました。リアルタイムデータが必要なため、更新をプッシュするためにWebSocketが必要であることは明らかでした。

それは概念実証から始まり、素晴らしい働きをしました。しかし、それを一般に公開したい場合は、ユーザーセッションを追加する必要があったため、ログイン機能が必要でした。そして、どのように見ても、websocketはどのユーザーを処理するかを知る必要があるため、websocketを使用してユーザーを認証するショートカットを採用しました。当たり前のようで便利でした。

実際には、接続を信頼できるものにするために静かな時間を費やす必要がありました。安価なWebSocketチュートリアルから始めましたが、接続が切断されたときに実装が自動的に再接続できないことがわかりました。socket-ioに切り替えると、すべてが改善されました。Socket-ioは必須です！

とはいえ、正直なところ、いくつかの素晴らしいsocket-io機能を見逃してしまったと思います。Socket-ioにはもっと多くの機能があり、最初の設計でそれを考慮に入れれば、より多くのことを得ることができると私は確信しています。対照的に、古いwebsocketをsocket-ioのwebsocket機能に置き換えただけで、それで終わりです。（部屋なし、チャンネルなし...）再設計により、すべてがより強力になった可能性があります。しかし、そのための時間はありませんでした。これは、次のプロジェクトで覚えておくべきことです。

次に、より多くのデータ（ユーザー履歴、請求書、トランザクションなど）の保存を開始しました。すべてをAWS dynamodbデータベースに格納し、AGAINでは、socket-ioを使用してCRUD操作をフロントエンドからバックエンドに通信しました。私たちはそこで間違った方向に進んだと思います。それは間違いでした。

• それは、Amazonのクラウドサービス（AWS）がRESTfulアプリケーション用の優れたロードバランシング/スケーリングツールを提供していることを知った直後のことです。
• CRUD操作のハンドシェイクを実行するために多くのコードを記述する必要があるという印象を受けました。
• 最近、Paypal統合を実装しました。私たちはなんとかそれを機能させることができました。しかし、繰り返しになりますが、すべてのチュートリアルではRESTful APIを使用しています。ウェブソケットで実装するために、サンプルを書き直したり再考したりする必要がありました。それでもかなり高速に動作しました。しかし、流れに逆らっているように感じます。

以上のことを踏まえて、来週ライブを行います。私たちは時間内にそこに着きました、すべてがうまくいきます。そして、それは高速ですが、スケーリングしますか？

両方の使用を検討します。各テクノロジーにはメリットがあり、すべてのソリューションに適したサイズはありません。

仕事の分離はこのようになります：

1. WebSocketは、セッションが必要なサーバーと通信するアプリケーションの主要な方法です。これにより、古いブラウザに必要な多くのハックが排除されます（問題は、これを排除する古いブラウザのサポートです）。

2. RESTful APIは、ブラウザキャッシュの恩恵を受けるセッション指向ではない（つまり、認証は不要）GET呼び出しに使用されます。この良い例は、Webアプリケーションで使用されるドロップダウンの参照データです。しかしながら。より頻繁に変更することができます...

3. HTMLおよびJavaScript。これらはwebappのUIを構成します。これらは通常、CDNに配置されることでメリットがあります。

4. WSDLを使用したWebサービスは、メッセージとデータの受け渡しのための明確に定義された標準を提供するため、エンタープライズレベルおよび企業間通信の最良の方法です。主に、これをDatapowerデバイスにオフロードして、Webサービスハンドラーにプロキシします。

これはすべて、SSLを介したセキュアソケットを使用できるHTTPプロトコルで発生します。

ただし、モバイルアプリケーションの場合、websocketは切断されたセッションに再接続できず（接続を閉じた後にwebsocketに再接続する方法）、それを管理することは簡単ではありません。したがって、モバイルアプリの場合は、REST APIとポーリングをお勧めします。

WebSocketsとRESTを使用するときに注意すべきもう1つのことは、スケーラビリティです。WebSocketセッションは引き続きサーバーによって管理されます。RESTful APIが適切に実行されるとステートレス（つまり、管理する必要のあるサーバーの状態がないこと）であるため、スケーラビリティーは垂直よりも水平に（安価に）向上します。

サーバーからの更新が必要ですか？

• はい：Socket.io
• 休みなしで

Socket.ioの欠点は次のとおりです。

• スケーラビリティ：WebSocketには、オープンコネクションと、Webスケールのための非常に異なるOpsセットアップが必要です。
• ラーニン：ラーニンの時間に制限はありません。物事は成し遂げられなければならない！

プロジェクトでは引き続きSocket.ioを使用しますが、RESTでうまく機能する基本的なWebフォームには使用しません。

WebSocket（またはロングポーリング）ベースのトランスポートは、主にサーバーとクライアント間の（ほぼ）リアルタイム通信に使用されます。チャットやある種のリアルタイムフィードなど、これらの種類のトランスポートが必要となるシナリオは多数ありますが、一部のWebアプリケーションのすべての部分を必ずしもサーバーと双方向で接続する必要はありません。

RESTはリソースベースのアーキテクチャであり、よく理解されており、他のアーキテクチャに比べて独自の利点があります。WebSocketは、リアルタイムでデータのストリーム/フィードにさらに傾斜します。これにより、リソースとフィードを優先または区別するためにサーバーベースのロジックを作成する必要があります（RESTを使用しない場合）。

このトランスポートがより広く普及し、データタイプ/フォームにとらわれない配信の形式でよりよく理解/文書化されるようになると、将来的にはsocketstreamのようなWebSockets中心のフレームワークがさらに増えると思います。ただし、RESTが多くのユースケースやシナリオで必ずしも必要とされない機能を提供するからといって、RESTを置き換える/すべきであるとは限りません。

それは良い考えではありません。標準はまだ確定されておらず、サポートはブラウザーなどによって異なります。これを行う場合、フラッシュやロングポーリングなどにフォールバックする必要があります。将来的には、おそらくそれはまだ行われませんサーバーはすべてのユーザーに接続を開いたままにすることをサポートする必要があるため、多くの意味です。代わりに、ほとんどのWebサーバーは、要求への迅速な応答と可能な限り迅速なクローズに優れているように設計されています。オペレーティングシステムでさえ、多数の同時接続に対応するように調整する必要があります（各接続は、より多くの一時的なポートとメモリを使用します）。できるだけ多くのサイトでRESTを使用してください。