私のWebサイトでは、クライアント(不明な人)が私のサービスと対話できるようにするパブリックAPIを作成したいと思います。その場合、従来のRESTAPIが適切に機能します。
ただし、クライアントにもイベントを送信できる必要があります。これらのイベントは、クライアントのHTTPリクエストとは関係ありません。「webhooks」がこれに対処する方法だと思いました。私がよく理解していれば、Webhookを使用すると、サービスはHTTP POSTリクエストをクライアントが指定したURLに送信し、このリクエスト内にイベントデータを含めます。
WebSocketは、この全二重通信のニーズに対するソリューションとしても使用できると思います。
私が知りたいのは、クライアントが私のサービスと通信するために実装するのが最も簡単な方法はどれですか?ここで重要なのはシンプルさです。難しいのは、クライアントがさまざまなテクノロジー(HTTPサーバーを備えた完全なWebサイト、サーバーを備えていないiOS / Androidアプリなど)を使用できることです。
REST API + Webhookを使用する場合、クライアントにどのような影響がありますか?Websocket?等?選択する方法は?
それが明確であることを願っています(しかし確かではありません)。ありがとう:)
Webhookはもっと簡単な解決策だと思います。はい、ご存知のとおり、Webhookを使用すると、APIを使用する開発者がバックエンドがイベントデータをPOSTするURLを登録します。これは、APIで使用される一般的なパターンです。
Webhookデザインを使用することの大きな利点は、クライアント/サーバー接続を開いたままにする必要がないことです。結局のところ、イベントが頻繁に発生しない場合(つまり、1時間に数回、または1日に数回のみ)、または一貫した接続を開いたままにすることが課題である場合、必要なときにのみ接続を確立する方がかなり効率的です。
APIプロバイダーであるWebhookを使用する際の課題は、状態変化の検出と信頼性の高いWebhook呼び出しメカニズム(つまり、応答しない、またはエラーをスローするWebhookレシーバーURLを処理する)を処理するイベントバックエンドシステムを設計することです。
開発者側でWebhookを使用する際の課題は、サーバーからのイベントPOSTデータをリッスンする信頼性の高いWebサーバーを立ち上げる必要があることです。
リアルタイムAPI(つまり、Websocket、Bayeux / CometDに基づく)は、ライブ接続が新しい接続を確立する必要がないことを意味するため、非常に優れています。これは、非常にチャットの多いセッションで特に役立ちます。さらに、完全に焼き付けられたライブラリを使用してサーバーとクライアントの手間のかかる作業を処理しているプロジェクトや企業がたくさんあります。それらの1つはFanout.ioであり、可能な場合はXMPP、Bayeux、およびWebsocketを利用して、わずか数行のコードでクライアント/サーバー間でメッセージをプッシュできます。
(私はファンアウトと提携していませんが、使用しました)
したがって、要約すると、Webhookは、実装に必要なアーキテクチャに既に精通していることが主な理由で単純であり、パターンはよく使われています。持続的接続アプローチに傾倒している場合は、Fanoutのようなツール/プラットフォームを検討します。これは、手間のかかる作業(つまり、サブスクライブ/パブリッシュ、同時接続スケール、クライアント/サーバーライブラリ)を処理するためです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加