【发布时间】：2013-04-11 10:57:35
【问题描述】：
最初的计划是写这篇博文，题为“Spotify 元数据 API 的效率低下：或者，Jackson 5 如何杀死我的浏览器”，但在最后一分钟改变了主意，因为我有错过的习惯文档中显而易见的，也许我错过了一个未记录的功能，或者其他人已经解决了这个问题 - 因此这个问题有一定的博客文章语气！
我正在开发一个小型网络应用，主要面向一小群人，它允许任何人更新 Spotify 播放列表。由于不是每个人都有 Spotify（尽管我不知道为什么！），因此该页面将使用歌曲更新数据库，因为在我的笔记本电脑上运行在 Spotify 中的应用程序会轮询数据库以获取更新，然后使用 Spotify 应用程序 API 更新播放列表，订阅播放列表的任何人都会收到更新。没关系，虽然我想使用推送而不是投票，但这是另一天的话题。
我搜索了一个用于 Spotify 元数据 API 的 Javascript 库，并找到了一个 (https://github.com/palmerj3/SpotifyJS)，尽管它基本上是一个包装器，并且仍然需要您自己解析 JSON。我想我可以做得更好，为最常见的字段（标题、艺术家、专辑、Spotify URI）做一些基本的解析，我开始开发自己的库/JQuery 插件。
按曲目搜索不是问题，它是对 spotify 元数据 API 的一次调用，结果很容易解析，将返回的艺术家与请求的艺术家（如果存在）相匹配，可以轻松地按标题/艺术家搜索。
按艺术家搜索（获取特定艺术家的所有歌曲列表）不过，这似乎是一个难题-**！据我从文档中可以看出，这就是过程。
- 搜索艺术家：这将返回与查询匹配的艺术家列表
- 对于每个艺术家，查找他们的专辑：这将返回一个专辑列表
- 查找每张专辑并检索曲目列表
- 将每首曲目的艺术家与搜索艺术家进行比较（如果匹配输出）
第一步将返回一个艺术家匹配的小列表，Foo Fighters 有 2 个，Silverchair 有 1 个，而 The Jackson 5 有 4 个。这个小列表变成了更多的专辑匹配 - 从内存 Foo Fighters 返回 112，这然后变成更多的曲目列表。从 Javascript/JQuery 的角度来看，这会导致菊花链式 AJAX 请求，对于每个步骤，并且在每个步骤中，针对 Spotify 服务器的大量几乎并发的 GET 请求。
我写的初始版本作弊并使用同步 AJAX，并且工作正常，因为每个请求都必须在下一个请求开始之前完成，但是，这会锁定浏览器一段时间，并消除使用反馈的可能性系统正在运行的用户。然后我切换到异步请求，一切都乱套了！您立即遇到了 Spotify 端的速率限制问题，它返回 502 bad gateway 的响应（顺便说一下，在 spotify 文档中未作为状态列出）或 503（JQuery 将两者都解释为状态代码 0），这很有趣，需要在 Firebug 中调试。我在客户端限制了请求，我发现每秒 1 次是正确的，以避免速率限制并确保我每次都得到包含数据的响应，但是，这会导致浏览器中的大量锁定，因为它已经向上并行 30 或 40 个 GET 请求，几乎同时返回（尽管有些请求在 15 多秒后响应！），然后解析所有 JSON 响应。
我研究了通过使用服务器端方法来减轻负载，尽管这也有缺点： 1.你没有避免API无法有效处理任务的基本问题 2. 对于一个繁忙的站点，带宽的使用会与服务器相冲突，服务器也会出现单个IP，对于多个用户，由于并行用户很快就会达到速率限制
服务器端确实提供了缓存，虽然这可能是有益的，为此我找到了一个 PHP 库 - metatune (https://github.com/mikaelbr/metatune)，宣传为“Spotify 元数据 API 的终极 PHP 包装器”，但不幸的是只提供与 Spotify 元数据 API 相同的基本查找/搜索 - 即：不列出艺术家的所有歌曲。
因此，我现在已禁用按艺术家搜索，直到找到合适的解决方案。
假设我没有遗漏任何东西，至少在我看来，这似乎不是一个高效的 API 设计，因为它鼓励您向 Spotify 服务器发出大量请求，这对我作为客户不利，并且不适合作为服务器的 Spotify。我不禁想到，如果有这样的要求：
ws.spotify.com/search/1/artist.json?q=foo+fighters&extras=tracks
那么这里讨论的问题就会得到缓解，单个请求将涵盖目前需要3组多个请求的内容；速率限制不会是一个大问题；大大减少了在客户端处理数据的开销； Spotify 处理的开销将减少，整个服务将更有效率。请求将返回一个非常大的数据集这一事实不是问题，因为 API 已经将数据拆分为“页面”。
所以，我向人群提出的问题： 1. 我是否遗漏了文档中明显的内容，或者是否有秘密请求？ 2. 在没有 API 请求的情况下，有人对如何让我的系统更高效有建议吗？ 3. 有没有人解决过这个问题？
感谢阅读！花了很长时间才回答这些问题，但我觉得有必要提供尽可能多的推理来找到最佳解决方案，而且它也说明了 API 的不足，我希望 Spotify 的人会注意到这一点！
最后顺便说一句，像这样的项目让我觉得我们已经将 Flash 换成了 Javascript，但性能仍然很差！其他人有同感吗？
干杯！ 袜子小偷
【问题讨论】：