ウェブサービスを作る際、コンテンツをすべて含んだHTMLを返すと反応が遅くなったり、定期的に一部を更新する場合に非同期で更新を行うことを考えます。
- HTTP(S)で情報を送信・取得する、いわゆるREST APIを使う
- WebSocketを使って双方向のやり取りを確立する
どちらにしようかなと思ったので特徴を見て比べてみます。
REST API
RESTは一意なURLに対して特定の処理をもたせるアークテクチャです（SOAPだと問題あるわけでもないけど今回はスルー）。
昔からクライアント（ブラウザ）側から非同期に通信を行うAjaxという方法がありました。現在はFetch APIによって簡単に非同期通信を行うことが出来ます。
メリット
- クライアント(javascript)、サーバ共に実装が容易
- 機能ごとに分離可能で拡張・管理がしやすい
デメリット
- 設計次第ではリクエストが大量に送られることになる
- 常にクライアント側からの通信になる
- サーバ側でのイベントを待つ場合には頻繁に無駄リクエストを送るか、ロングポーリングのようなやり方になってしまう
WebScoket
以前にGOで試したこともある双方向通信のための規格です。
ws:、wss:を使って通信します。
コネクション確立後クライアント・サーバどちらからでも通信を始めることが可能。
メリット
- サーバ主動でメッセージが送れる
- リクエスト処理の負担やヘッダ等通信の量が減る
デメリット
- クライアント、サーバ共に実装が複雑になる
- 特にリクエストとレスポンスが対にならない部分は慣れがいる
- コネクション確立中はリソースを占有する
- サーバの更新、再起動をしにくい（コネクションが破棄されるため）
まとめ
最初はWebSocketを使う以上は全部WebSocketで通信したほうがいいかと思ったけど実装がどんどんごちゃごちゃしていきました。内容で使い分けが必要かもしれない。
頻度が少なくユーザ主導で発生するものはREST API、頻度が多かったりサーバ主動で更新する場合にはWebSocketを使うのがよさそう。
この辺は適当な取引所のネットワークを見てみるとよく分かります。
現在価格、チャートや板の変化などはwss、注文などはAPIで行われていました。