2

私の質問への返信ありがとうございます：これはイベントを取得するときのBox APIv2のバグですか？

これはこれに関連する新しい問題です。問題は、イベントを追跡するために以前の呼び出しから取得したnext_stream_positionを確実に使用できないことです。

このシナリオを考えると：

次の2つのGETHTTPクエリがあるとします。

1. GET https://api.box.com/2.0/events?stream_position=1336039062458

これは、myfile.pdfの1つのファイルエントリと次のストリーム位置を含むJSONファイルを返します= 1336039062934

2. GET https://api.box.com/2.0/events?stream_position=1336039062934

この呼び出しは、最初の呼び出しから取得したストリーム位置を使用します。ただし、JSONには、最初の呼び出しとまったく同じmyfile.pdfのファイルエントリが含まれていることが返されます。

最初の呼び出しがストリーム位置を与える場合、それはその正確な時間のマークとして使用されるべきだと思います（例：時間A）。後続のクエリでそのストリーム位置を使用する場合、「時間A」より前のイベントは返されません。

これはバグですか？または、APIを間違った方法で使用しましたか？

どうもありがとう。

4

3 に答える 3

2

Box イベントは現在、過去に約 5 秒のウィンドウを提供するため、イベントを見逃すことはありません。

送信するイベントを約 5 秒遅らせて、イベントの重複を排除することを検討しましたが、この時点でダイヤルをよりリアルタイムに向けました。完全に重複除去されたストリームをご希望の場合はお知らせください。これは低速でした。

今のところ (ベータ版)、重複するイベントをチェックして破棄するようにクライアントを作成するのが最善です。ペイロードに event_id を追加しようとしているので、重複を排除できます。それまでは、イベントの種類に応じて、多くのフィールドを確認する必要があります。おそらく、価値があるというよりも、より挑戦的です。

于 2012-05-03T19:38:25.777 に答える
2

Box の /events エンドポイントは、Box アカウントに関連するすべてのイベントの信頼性の高いリストを提供することに重点を置いています。イベントは、stream_position と呼ばれる時系列のリストに対して登録されます。/events API をヒットして stream_position を渡すと、現在の stream_position または chunk_size のいずれか小さい方まで、そのストリーム位置の少し前に発生したイベントで応答します。タイミング ラグと、一部のイベントを見逃さないようにするための設定により、/events API を呼び出したときに重複したイベントを受け取る場合があります。また、既に受信したイベントの「前」のように見えるイベントを受信する場合もあります。私たちの哲学は、暗闇の中にいて重要なことを見逃すよりも、何が起こったのかを知る方が良いということです.

于 2012-05-03T17:43:18.857 に答える
0

イベントが重複しているかどうかを判断できるようにするために、各イベントに一意の event_id を追加しました。event_id により、後続の GET /events 呼び出しから受け取る応答の重複を排除できるようにすることが私たちの意図です。

これは、ペイロードの例を含む更新されたドキュメント (こちら) に反映されていることがわかります。

于 2012-05-10T08:12:19.047 に答える