感谢您回复我的问题：获取事件时这是Box API v2的错误吗
这是一个与此相关的新问题。问题是我无法可靠地使用从以前的调用中获得的next_stream_position来跟踪事件。
给定此场景：
给定以下两个 GET HTTP 查询：
1. GET https://api.box.com/2.0/events?stream_position=1336039062458
这个返回 JSON 文件，其中包含 myfile 的一个文件条目.pdf下一个流位置 = 1336039062934
2. GET https://api.box.com/2.0/events?stream_position=1336039062934
此调用使用我从第一次调用中获得的流位置。但是，它返回 JSON 包含与第一次调用完全相同的 myfile 文件条目.pdf。
我认为如果第一次调用给出了流位置，则应将其用作该确切时间的标记（例如：时间 A）。如果我在后续查询中使用该流位置，则不应返回"时间 A"之前的任何事件。
这是一个错误吗？还是我以错误的方式使用了 API？
非常感谢。
的/events 端点专注于为您提供与您的 Box 帐户相关的所有事件的高度可靠的列表。事件是根据我们称之为stream_position的时间序列列表注册的。当您点击/events API 并传入stream_position时，我们会以在该流位置之前发生的事件（直到当前stream_position或chunk_size，以较小者为准）来响应您。由于计时滞后以及我们确保您不会错过某些事件的偏好，您在调用/events API 时可能会收到重复的事件。您可能还会收到看起来像是"之前"事件的事件，但这些事件是您已经收到的。我们的理念是，您最好知道发生了什么，而不是在黑暗中错过重要的事情。
目前为您提供一个大约 5 秒的过去窗口，这样您就不会错过某些事件。
我们考虑过将发送给您的事件延迟大约 5 秒，并删除我们这边的事件重复，但此时我们已将拨号盘更多地转向实时。 让我们知道您是否更喜欢完全取消重复的流，那速度较慢。
目前，（在测试版中）如果您编写客户端来检查重复事件并丢弃它们，那将是最好的。 我们将向有效负载添加一个event_id，以便您可以对其进行重复数据删除。 在那之前，你必须查看一堆字段，具体取决于事件类型...... 它可能更具挑战性，因为它的价值。
为了帮助您确定事件是否重复，我们现在为每个事件添加了一个唯一的event_id。 我们的目的是event_id允许您删除从后续 GET/events 调用中收到的响应。
您可以在此处的更新文档中看到这一点，包括示例有效负载。