在典型的rest api中，您可以获得以下所有书籍：
GET /books但是，我希望能够轮询服务器（例如，每10秒）以获取任何更新的书籍，而不必重新获取我已经获取的所有书籍。我的第一个想法是使用更新的时间戳。
例如，如果在上一个请求中，最新的图书在 2020-06-01 10:30:25.125 ，我可以做如下请求，以获取在该时间戳之后更新的所有书籍。
GET /books?updated_at_gt=2020-06-01-10-30-25-125这在大多数情况下都有效。不过，也有一些角落的情况。
问题
这种方法的问题是 updated_at 时间戳精确到最接近的毫秒。如果在同一毫秒内更新多个记录，则会出现问题。这听起来很少见，但可能发生在批量编辑上。
例如，考虑以下事件序列：
第1册更新为20.000000s。因此 updated_at 存储为： 2020-06-01 10:30:25.000 第二册于25:125000更新。因此 updated_at 存储为： 2020-06-01 10:30:25.125 25.125250秒 GET /books 会得到书1和书2，如预期的那样。
第三册更新于 25.125455s . 因此 updated_at 也存储为： 2020-06-01 10:30:25.125 （同第二册） GET /books?updated_at_gt=2020-06-01-10-30-25-125 我会想念第三本书的。
变通办法
我的工作是在第一次执行api调用时 2020-06-01 10:30:00.200 ，它将实际获取服务器请求时间之前50ms更新的所有书籍。
例如，考虑相同的场景：
第1册更新为20.000000s。因此 updated_at 存储为： 2020-06-01 10:30:25.000 第二册于25:125000更新。因此 updated_at 存储为： 2020-06-01 10:30:25.125 25.125250秒 GET /books 将在24.625250之前更新所有书籍. 所以它会得到第一本书，而不是第二本。
第三册更新于 25.125455s . 因此 updated_at 也存储为： 2020-06-01 10:30:25.125 （同第二册） GET /books?updated_at_gt=2020-06-01-10-30-25-000 我会拿到第二册和第三册。
这似乎是一项复杂的工作。
有更好的办法吗？
2条答案
按热度按时间sczxawaw1#
抱歉，由于声誉问题，我还不能添加评论。
老实说，我不完全明白为什么它会丢失，不管额外的毫秒细节，如果你不存储它们，如果你在更新时存储的内容完全相同，它怎么会丢失呢？
既然如此，为什么不设置一个中间的情况。存储更新的时间，但要记录您上次打电话的时间，并在旧时间和新时间之间进行比较
所以你要确保你的第一个查询总是在你关心之前就已经完成了
更新时间为\u gt>2020-01-01-00-00-00-000，更新时间为\u gt<=要存储的当前时间（最长为毫秒等）。
然后，您将存储<=的时间，以便下次，它将在时间更新。这样一来，它就永远不会归还它在<=时所做的书。
所以
查询一个更新的\u gt>2020-01-01-00-00-000和更新的\u gt<=2020-06-01 10:35:01.1245665
查询二
更新时间：2020-06-01 10:35:01.1245665和<=2020-06-01 10:35:11.1245665
举个例子。
h79rfbju2#
可以使用epoch时间传入api。2020-06-11 5:31:53 am gmt的纪元时间是1591853513。epoch时间可以精确到毫秒，所以一旦服务器接收到epoch时间，它就可以直接减去毫秒，并根据它返回所需的书籍。参考-https://www.epochconverter.com for 历元转换器。使用epoch时间将是一个更干净的解决方案，而不是在查询参数中传递日期时间值。
另一个解决方案-如果可以对代码库和数据库进行修改，我建议您添加一个标记，该标记将针对get api调用中发送的所有书籍进行更新。这样你就不必检查任何时间，只需检查旗帜。