Question

在过去一周左右的时间里，我们收到了一个用户在我们的应用程序文件列表中缺少文件的报告。我们起初有点困惑，因为他们说他们只有几个文件符合我们的查询字符串，但通过一些工作，我们可以通过向我们的Google云端硬盘添加大量文件来重现他们的问题。以前我们一直假设人们的文件少于100个，并且没有进行分页以避免多个files.list请求。

在切换到使用分页后，我们注意到在我们的一个测试帐户上发送了数百和数百个files.list请求，并且大多数响应不包含任何文件，但确实包含nextPageToken。我会在获得屏幕截图后立即更新 - 但客户端发送了足够的请求来加热计算机并快速耗尽电池。

我们还发现，基于查询的内容即使它匹配相同的文件，它也会对检索完整文件列表所需的请求数量产生巨大影响。例如，在查询参数中将'='切换为'contains'会显着减少请求的数量，但我们不保证这是一个合理且可通用的解决方案。

这是预期的行为吗？我们可以做些什么来减少我们发送的请求数量吗？

我们正在使用以下代码检索由我们的应用程序创建的导致问题的文件。

runLoad: function(pageToken)
{
    gapi.client.drive.files.list(
    {
        'maxResults': 999,
        'pageToken': pageToken,
        'q': "trashed=false and mimeType='" + mime + "'"
    }).execute(function (results)
    {
        this.filePageRequests++;

        if (results.error || !results.nextPageToken || this.filePageRequests >= MAX_FILE_PAGE_REQUESTS)
        {
            this.isLoading(false);
        }
        else
        {
            this.runLoad(results.nextPageToken);
        }
    }.bind(this));
}

Answer 1

这可能是，但可能不应该是正确的行为。

通常在使用drive.file范围时发生。（我认为）正在发生的是API层正在获取所有文件，然后删除当前作用域/查询之外的文件，并将剩余部分返回到客户端应用程序。理论上，一个特定的文件页面可能没有范围内的文件，因此返回的数组是空的。

正如您所见，这是一种非常低效的方式，但这似乎就是这样。您只需继续关注下一页链接，直到它为空。

关于＆＃34;我们可以做些什么来减少我们发送的请求数量？＆＃34;

您已将最高结果设置为999，这是显而易见的一步。请注意，我已经看到此值触发内部错误（超时？），表现为500错误。您可能希望牺牲效率来保证可靠性并坚持默认值100，这似乎是更好的测试。

我不知道您发布的代码是您的实际代码，还是仅仅是简化的插图，但您需要确保处理401错误（授权失效）和500错误（有时可通过重试恢复）

驱动API files.list返回nextPageToken，其中包含空项结果

1 个答案: