[PHP][API]第 7 章: リアルタイム通信-PHPチュートリアル-php.cn

第 6 章では、API の設計について学び、独自の API を構築することで実際の例をいくつか見ていきました。さらに、私たちは得るのが難しい知識をたくさん持っているので、今では生産性を高めることができます。 API を機能させる方法を確認する準備が整いました。この章では、API を介してリアルタイム通信を実現する 4 つの方法を学びます。

統合

により、会話が容易になります。まず、なぜ API が役立つのかを思い出してください。第 1 章を振り返ると、API を使用すると 2 つのシステム (Web、コンピューター、スマートフォン) 間でデータを簡単に共有できると述べました。シンプルな共有により、システムを接続して統合することができます。人々は統合を好むのは、それによって生活がとても楽になるからです。統合を使用すると、1 つのシステムで何かを行うと、他のシステムが自動的に更新および同期できるようになります。

私たちの目的のために、統合を 2 つのカテゴリに分けます。まず、「クライアント主導型」、つまり人々はクライアントに影響を与え、サーバー上でデータを更新したいと考えていることを理解します。もう 1 つは、「サーバー側ドライバー」と呼ばれるもので、ユーザーがサーバー上で変更を行う場合、その変更をクライアントに通知する必要があります。

このように統合を分割する理由は単純な事実です。通信を開始できるのはクライアントだけです。クライアントがリクエストを行うと、サーバーは応答するだけであることに注意してください。この制限の結果、変更はクライアントからサーバーに簡単に送信できますが、サーバーからクライアントに送信するのは困難になります。

顧客主導の統合

顧客主導の統合がなぜ簡単であるかを示すために、先ほど説明したピザショップと注文 API に戻りましょう。 APIを使用してリリースしたモバイルアプリについて話しましょう。この場合、ピザ店の API がサーバー、モバイルアプリがクライアントになります。顧客はアプリを使用してピザを選択し、ボタンをクリックして注文を送信します。ボタンが押されるとすぐに、アプリはピザ屋の API にリクエストを行う必要があることを認識します。

平たく言えば、人がクライアントと対話するとき、クライアントはデータがいつ変更されたかを知ることができるため、サーバーに知らせるために API を求めることができます。遅延はまったくなく (したがってリアルタイムです)、人間によって行われるリクエストは 1 つだけであるため、プロセスは非常に効率的です。

サーバー主導の統合

ピザの注文が送信されると、顧客はピザがいつ準備できるかを知りたいと思うかもしれません。このアップデートを API 経由で提供するにはどうすればよいでしょうか?これは少し難しいです。顧客はピザを作るために何もしません。彼らはピザ屋でピザを準備し、注文のステータスを更新するのを待つだけです。言い換えれば、サーバー上でデータが変更されるとき、クライアントはそれについて知る必要があります。ただし、クライアントがリクエストを行うことができない場合、私たちは行き詰まってしまいます。

この問題の解決策は、2 番目の統合ディレクトリを使用することです。必要なソフトウェア開発者は、クライアントのみのリクエストの制限を克服するためにさまざまなソリューションを考え出しました。確認してみましょう。

ポーリング

リクエストを送信できるのはクライアントだけですが、最も簡単な解決策は、クライアントがサーバーを更新する必要があるときにサーバーを更新し続けることです。これは、ポーリングと呼ばれる同じリソースを繰り返し要求することで実行できます。

ピザショップにポーリングすると、注文のステータスは次のようになります:

このアプローチでは、クライアントがリクエストを送信する頻度が高くなるほど、クライアントはリアルタイム通信に近づきます。クライアントが 1 時間ごとにポーリングしない場合、最悪の結果は 1 時間の遅延が発生し、サーバーが変更されてもクライアントがそれに気付かないことです。毎分ポーリングすることで、サーバーは効果的に同期を保つことができます。

もちろん、このアプローチには大きな欠陥があります。これは非常に非効率的です。クライアントから送信されたリクエストのほとんどは、何も変わらないため無駄になります。さらに悪いことに、更新を高速化するには、ポーリング間隔を非常に短くして、クライアントがより多くのリクエストを送信できるようにする必要があるため、ますます非効率になります。このアプローチは拡張が困難です。

ロングポーリング

リクエストが無料であれば、誰も効率を気にせず、誰もがポーリングを使用するでしょう。しかし、残念ながら、リクエストの処理には代償がかかります。 API がより多くのリクエストを行うには、より多くのサービスを使用する必要があり、より多くの費用がかかります。このレベルの退屈さは Google や Facebook のレベルに達する可能性があり、多くの非効率性の代償を払うことになります。したがって、クライアントがサーバーから更新を取得するこのメソッドの最適化には多大な労力が費やされました。

ロングポーリングと呼ばれるポーリングから最適化されます。ロングポーリングでも同じ考え方が使用され、クライアントは繰り返しサーバーに更新を要求しますが、異なる点は、サーバーがすぐには応答しないことです。逆に、サーバーが変更されると、更新に応答します。

ポーリングの例を思い出してみましょう。今回はサーバー側でロングポーリングを使用します。

このテクノロジーは非常にスマートです。これは、サーバーからの遅い応答に対する規則がないことを除いて、クライアントの最初の要求の規則に従います。クライアントとサーバーが同意し、サーバーがクライアントのリクエストを保持し、クライアントがサーバーとの接続を維持できる限り、機能します。

ロングポーリングは非常に賢いですが、いくつかの欠点もあります。技術的な詳細については省略しますが、サーバーが同時にどれだけのリクエストを保持できるか、サーバーとクライアントが切断された場合にどのように回復するかなど、いくつかの懸念があります。さて、場合によっては、投票だけでは十分ではないと言えます。

Webhook

ポーリングが廃止されたとき、ある革新的なソフトウェア開発者は、「すべての問題の原因がクライアントだけがリクエストを行えるのであれば、このルールを削除してもいいのではないか?」と考えました。その結果、クライアントがリクエストを送信してリッスンできるテクノロジーである Webhock が誕生し、サーバーが更新を簡単にプッシュできるようになります。

サーバーにリクエストをクライアントに送信させるため、これが不正行為のように聞こえる場合も、心配しないでください。騙されているわけではありません。クライアントをサーバーとしても機能させると、Webhook が機能できるようになります。このテクノロジーを見ると、クライアントがリクエストをリッスンできるように簡単に拡張でき、2 つの通信方法が可能になる場合があります。

Webhook の基本を見てみましょう。最も単純な形式では、Webhook では、クライアントがイベントを受け入れることができるコールバック URL を提供する必要があり、サーバーにはユーザーがコールバックを入力できる場所が必要です。その後、サーバー上で何かが変更されると、サーバーはクライアントのコールバック URL にリクエストを送信して、クライアントに更新について知らせます。

私たちのピザ屋と比較すると、プロセスは次のようになります。

この解決策はとても良いです。変更はサーバー上で発生するとすぐにクライアントに送信されるため、真のリアルタイム通信が可能になります。さらに、Webhook は更新ごとにリクエストが 1 つだけであるため、非常に効率的です。

Webhook を購読する

Webhook に基づいて、作成プロセスを動的にし、サーバー側でコールバック URL を手動で入力する必要がない、多数のソリューションが登場しました。 HTTP サブスクリプション仕様、Restful Webhook、REST Hook、PubSubHubbub について聞いたことがあるかもしれません。これらすべてのソリューションは、サブスクリプションプロセスを決定しようとします。このプロセスでは、クライアントはサーバーに、関心のあるイベントと、コールバック URL が送信する更新を伝えます。

それぞれの解決策は問題の解決方法が若干異なりますが、一般的なプロセスは以下と同じです。

サブスクリプションベースの Webhook には多くの約束があります。これらは効率的でリアルタイムであり、人々にとって使いやすいものです。 REST の採用と同様に、Webhook の形式で API をサポートする波が高まり、ますます一般的になってきています。

それでも、将来的には、ポーリングとロングポーリングがその一部になるでしょう。すべてのクライアントがクライアントと同じように動作するわけではありません。スマートフォンはその代表的な例であり、技術的な制限により Webhook アプローチが利用できません。テクノロジーが進歩するにつれて、すべてのデバイス間でリアルタイム通信を容易にするための新しい方法が登場します。