2012-02-07 26 views
0

私のSaaS製品は、イベント通知をwebhooksとして投稿します。この質問は、私がwebhookのURLに投稿する失敗事例を処理することです。webhook urlの呼び出しに失敗した場合のデータ処理

イベントデータを投稿するURLから200 OK応答コードを受信しなかった場合、そのイベント通知を失敗としてマークし、再試行プロセスを開始します。現在、イベントデータの一部として送信しなければならないデータのIDを格納し、再試行ごとにDBからフェッチします。

他人がこれをどのように処理しているのか見たいだけでしたか?私が考えることのできるもう一つのことは、実際のペイロード(JSONまたはXML形式)をDBに格納し、それぞれの再試行時に送信することです。しかし、これにより発生する可能性のあるデータ同期の問題を、イベントレシーバーがどのように処理すると思いますか?

答えて

1

Webhookレシーバに、エンドポイントをサービスに登録するときにデータを再POSTするかどうかを選択する必要があるように思えます。また、サービスがさまざまなレスポンスコードをどのように処理するのか明確な文書を提供することを強くおすすめします。

同期の問題を電子メールでエンドポイント管理者に通知する価値があります。これは、常に自分のサービスやPOSTテストデータを定期的にpingすることができるので便利です。

また、次の点を考慮してください。サービスが失敗した場合どうなりますか。同期が重要な場合、サービスとエンドポイントはその問題をどのように解決しますか?

あなたはあなたが投稿しているデータの種類とあなたが恐れている正確な同期の問題についてあまりに多くのコンテキストを提供していませんでした。もっと共有できますか?

編集:ここはhow MailChimp handles this issueです。彼らはあなたと同じ船にいるのは明らかです。

イベントはあなたがオンになっていることが発生した場合、我々はあなたが指定したURLにHTTP POSTリクエストをお送りします。そのURLが利用できない場合、または応答に時間がかかりすぎる場合(15秒を超える場合)、リクエストをキャンセルして後で再試行します。再試行は、1時間15分の間に増加する間隔で行われます。これらの時間枠は、ユーザーからのフィードバックを受け取ると調整される可能性があります。

イベントごとに、イベントに基づいてさまざまなデータが返されます。以下は、各イベントのサンプルデータです。上記のPostBinツールを使用して簡単に確認することもできます。一般に、各イベントにはタイプと、イベントのタイプを追跡し、イベントのタイムスタンプ(GMT!)を得るのに役立つfired_atフィールドがあります。

関連する問題