私は最近、RESTful Web サービスを使用して電話イベント (回線呼び出し、内線応答、通話クリアなど) を利用できるようにしたい電話システム ベンダーとの統合の実現可能性を調査するよう依頼されました。
REST はリクエスト/レスポンス プロトコルであり、パブリッシュ/サブスクライブを行っていることを指摘しました。彼らが提案していた解決策は、ブロックする HTTP REST リクエストを作成し、イベントが利用可能になった場合 (またはタイムアウトした場合) に最終的に応答することでした。
いずれにせよ、次のイベントを取得するために別のリクエストが行われ、それが無限に繰り返されます。
この考えにはうんざりしましたが、iPhone の「プッシュ」電子メールがこのように動作することは確かでした。
これは REST の合理的な使用法ですか?
これは、RESTアーキテクチャスタイルではうまく機能しないと言えます（主に、RESTがステートレスクライアントサーバーの相互作用に制約しているためです）。ただし、Webには長いポーリングを実行するソリューションが豊富にあり、Webの精神に従わなくても、多かれ少なかれ機能します。
まず、アーキテクチャに関する注意：REST内にpub / subを実装するということは、パブリッシャーがリストにアイテムを追加し、それがサブスクライバーに提供されることを意味します。サブスクライバーはリストをポーリングします。非同期ではありますが、メッセージの順序と（形式の）保証された配信を維持しながら、1回限りの配信を保証するためにこれを作成する方法があります。それは本当にうまくスケーリングし、そして本当に弾力性があります。
私の最初のアドバイスは、それをオプションにして、長いポーリングを実行できない（または実行したくない）クライアントが実行できるようにすることです。一般的なクライアント（Googleなど）の場合、デフォルトでは長いポーリングは実行されず、サーバーはクライアントとサーバー間の特別な共有理解によって長いポーリングを開始します。 。その共有された理解は、カスタムメディアタイプまたはカスタムリンク関係、あるいは一般的なクライアントが知らないカスタムHTTPヘッダーでさえあり得ます。ロングポーリングをサポートするクライアントは、ロングポーリングの機能を検出し、必要に応じてそれを呼び出し、ロングポーリングが失敗した場合（たとえば、仲介者が何らかの方法でブロックした場合）に通常のポーリングにフォールバックするようにコーディングされます。
そして、HTTPの上でこれを実行しようとする代わりに、HTTPの意図に違反せず、トランスポートプロトコルとしてHTTPを効果的に使用するために、非HTTPソケットを使用することをお勧めします。cometdを参照してください。
私の他のアドバイスは、クライアントがどのように「リアルタイム」でなければならないかという質問をすることです。数秒の遅延が許容できる場合は、定期的なポーリングを使用してこれを解決するキャッシュ可能な性質により、非常に多数のクライアントであっても、定期的なポーリングで多くのことを実行できます。