使用 REST API 的 Dropbox 差异/增量上传答案

【问题标题】：Dropbox differential/incremental uploads using REST API使用 REST API 的 Dropbox 差异/增量上传
【发布时间】：2012-09-27 07:17:54
【问题描述】：

我们知道 Dropbox 桌面客户端使用二进制 diff 算法将所有文件分解成块，并且只上传它在云中还没有的块 (https://serverfault.com/questions/52861/how-does-dropbox-version-upload-large-files)。

不过，据我所知，Dropbox API 只能在需要同步时上传整个文件（/files_put、/files (POST)）。

有没有办法使用 Dropbox API 进行差异/增量同步，即像桌面客户端那样只上传文件的更改部分？

如果无法做到这一点，那么使用 Dropbox API 定期同步具有微小更改的大文件的最佳做法是什么？

【问题讨论】：

好问题——你找到答案了吗？
很遗憾没有。如果我发现任何相关内容，我会回到这篇文章。
AFAIK，您可以使用 HTTP 范围检索请求 (w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2) 按块下载文件 Dropbox HTTP API 支持它（至少用于下载文件），不确定上传。查看 /files(GET) 方法的更多详细信息：dropbox.com/developers/core/docs

【解决方案1】：

不幸的是，这是不可能的，我怀疑它可能永远都不可用。

在做了一些研究之后，我发现了一个将 delta-syncing 集成到 API[*] 中的功能请求。 Dropbox 没有回应，社区也没有支持这个请求。

我会做出一个有根据的猜测，Dropbox 之所以没有提供此功能，而且很可能永远不会提供，是因为这在不知名的开发人员手中是一个危险的功能。

考虑您编写的应用程序使用这种增量更改更新系统来更新大文件的情况。您彻底测试您的应用程序并将其发布到应用程序商店。在您首次发布和大量下载后几周，您开始收到差评和投诉，因为您设法错过了一个非常具体的测试用例。

在这个特定的、有问题的情况下，您错误地计算了 1 个字节的差分偏移量。不好了！您现在已经为数百名用户损坏了数千个文件！

考虑到这种可能性，我个人认为我会要求 Dropbox 永远不要提供这样的开发功能。如果他们将这样的功能集成到 API 中，他们将打破他们的第一个目的——为您的重要文件提供一致、安全和可靠的云备份。

[*]：这是原来的参考位置，但现在是死链接。

【讨论】：

我不同意你的结论：能够犯错误不应该成为不提供此类功能的理由。您不能（也不应该）照看开发人员。只要你不故意让事情变得危险，并在事情可能变得危险时提供很好的警告和剩余部分，那么我认为提供这样的东西没有问题。
您可以通过通常的上传或删除方法损坏数千个文件，所以我认为您的想法没有任何意义。
只要失败的责任显然不在 Dropbox 一方，你的例子对 Dropbox 来说不是问题。无论如何，我希望 Dropbox 至少会发布一个 API 来指定要附加到文件的块，我会有一个很好的用例。