Google drive api 文件资源中是否存在子项或子项计数？

由

files.list

和其他方法返回的

files

资源包括每个文件的父级列表。如果

文件

还包含一些儿童指示，这将非常有用。最好是具有子级计数的integer属性，但可以使用指示子级是否存在的布尔标志。谷歌的伙计们，这可以添加到API中吗

---

我之所以这么问，是因为我正在编写一个应用程序，该应用程序显示用户的Google Drive内容的可扩展树。树最初显示其驱动器的顶层，所有文件夹都已折叠。当用户展开文件夹时，新的查询被发送到GDAPI以获取每个文件夹的内容。但是，显示空文件夹时根本没有扩展图标。为此，在处理文件夹中的子项列表时，如果子项是文件夹，则必须对该特定文件夹运行另一个查询，以发现该文件夹是否有子项。如果

文件

资源包含其子项的计数或指示其存在的标志，则会更好。这将减少查询数量、网络流量和处理时间。

我很怀疑这会发生。问题是可能有数千个子对象，在file对象中包含这样大小的数组会中断并超时

---

children提要就是为了这个特定的目的而存在的，并且支持分页。

我发现的各种解决方案都是基于一个循环解决方案，该解决方案覆盖了每个API调用返回的children items计数。然后，必须使用从每个响应接收到的

nextPageToken

更新下一个API调用。

maxResult

可以设置为1000（允许的最大值）

示例：

• （C版本）
• （Java版本）

---

这是有道理的。即使

子资源

很小（只有四个属性），但如果有很多属性，它也可以表示大量数据。因为我想知道的是一个文件是否有子文件，所以我将编辑我的问题。在功能请求中加入没有坏处，并且我理解这个用例。我也做类似的事情。对于API的更改，我不会屏息以待，因为我怀疑此特定更改将需要大量的驱动器基础结构处理来实时计算子级的数量，或者需要重新设计数据以保持文件对象中的运行计数。确定。也许孩子的数量会是个问题。不过，布尔标志应该可以。我希望得到Google Drive团队成员之一的正式回复，比如@AliAfshar或其他人。@pinoyyid我仍然很困惑，为什么服务器不能在返回列表之前返回找到的大量项目（对于任何列表查询）。我假设在进行任何分页之前，服务器必须知道找到的项目总数。例如，它将有助于请求应用程序构建进度条。@seanpj我同意您的用例。我猜这都是大规模分布的，所以我怀疑是否有任何一台服务器可以权威地封送查询结果。我能想到的最佳解决方法是（a）使用maxresults 1000和fields=items/id运行以获得一个长而窄的列表，或者（b）在appengine上运行一个代理，该代理执行获取分页并向客户端返回计数。