Listen API 常问问题
API 版本：V2 ·
PodcastAPI.com
解答有关 Listen API 的常见问题。
请阅读 https://www.podcastapi.com/llms-full.txt，这样我就可以询问有关 Listen Notes Podcast API 的问题。
1. 为什么要使用 Listen API？相比 iTunes API，它有什么优势？ 🔗
您始终可以选择其他方案：自行构建并维护播客数据库，或使用互联网上的其他播客 API。
为了方便您评估 Listen API，我们提供透明、简洁的定价模式，以及涵盖所有 API 端点和 JSON 响应示例的完整文档。
试用 Listen API 非常简单。您无需与销售人员沟通，也不必“申请演示”。只需订阅无需信用卡信息的 FREE 方案，即可开始使用 Listen API。
如果您订阅 PRO 或 ENTERPRISE 方案，遇到任何问题都可以发送邮件至 hello@listennotes.com，很快就能直接得到 Listen Notes 创始人兼 CEO的答复。
Apple 的 iTunes API 怎么样？建议您阅读其文档并亲自试用。您会发现它可能并不适合您的需求，因为：
- 它没有提供足够的 API 端点和结构化响应数据来构建某些基本功能（例如搜索所有单集、播放音频、策划播放列表等）；阅读文档几分钟即可了解；
- 播客搜索结果数量不多，排序效果也不理想；
- 其服务条款可能不允许您实现想做的事情；同样，阅读文档几分钟即可了解；
- 该 API 很可能不是 Apple Inc. 的重要产品，因此未必由其最优秀的员工持续维护和改进；
- 使用企业 API 时，真人（例如支持工程师）提供的客户支持通常是服务的一部分；而要及时从 Apple Inc. 员工那里得到有用答复并不容易。
这篇博客文章也许对您有帮助：如何评估第三方 RESTful API？
2. 构建一个播客数据库到底有多难？ 🔗
构建一个像样的播客数据库是一项持续投入。技术上并不困难，但构建和维护都需要时间和资金，包括服务器成本和工程师薪资等。就像拥有汽车或房屋一样，购买时的一次性支出远低于长期维护成本，其中包括税费、保险、意外维修，最重要的还有您的时间。
自行构建和维护播客数据库前，需要考虑以下问题：
- 互联网上至少有 3,831,426 个播客和 196,768,984 个单集，而且内容规模增长越来越快。您需要自行托管数据并确保数据保持最新。
- 在 3,831,426 个播客和 196,768,984 个单集的规模下，RSS 源和音频 URL 的变更比想象中更频繁。您需要全天候投入自动化工具和人工流程来清理数据；这些工作不可或缺，却不会被用户直接看到。
- 如果需要按关键词搜索 3,831,426 个播客和 196,768,984 个单集，就必须自行构建搜索引擎。搜索引擎的界面看似简单，后端基础设施却极其复杂。Google 这个“简单网站”在 2022 年拥有 17.5 万名全职员工和数十万名承包商，自有其原因。
- 互联网上有大量虚假播客，例如机器生成的音频。黑帽 SEO 从业者会为建立链接制造许多并非供真人收听的虚假节目。您必须同时部署自动化和人工流程，避免把这些内容收入数据库。有趣的是，Google 拥有专门的网页垃圾内容团队；Listen Notes 也投入了大量资源处理虚假播客。
- 如果数据库和搜索引擎需要全天候运行，还必须投入精力避免服务器中断。
- 一名合格的全职软件工程师需要多少薪资？与其支付几名内部工程师的工资，您是否更愿意为第三方云服务（例如我们的 API）付费？
坦率地说，自行构建和维护播客数据库最昂贵的部分是机会成本。这关乎取舍：用于构建数据库的时间，就无法用于开发您的应用或网站。
使用 Listen API 可以让您立即开始项目中最令人兴奋的部分。此外，我们运营着热门的播客搜索网站 listennotes.com，每月有超过 2,000,000 名用户；这些用户在保持数据库更新方面发挥着重要作用。例如，他们会帮助提交缺失的播客并修正错误数据。借助全球用户全天候的帮助，我们得以维护一个高质量的播客数据库。
3. 你们是否在积极维护 API？未来会继续维护吗？ 🔗
是的，而且会继续。
Listen API 为面向用户的网站 ListenNotes.com 提供支持，也会受益于 ListenNotes.com 的大多数后端改进。
我们从 2017 年运营至今，并计划长期继续运营。
4. 如果我们使用 Listen API，而它以后停止服务怎么办？ 🔗
您的担忧很合理。我们都知道，没有任何在线服务或公司能永远存在。例如，Google 也终止过许多自己的产品。
如果我们决定关闭 Listen API，会至少提前 12 周通知您；届时您还可以用合理的低价购买最新的完整数据库导出（所有播客和所有单集）。
Listen Notes 很可能比许多资金充足的初创公司甚至上市公司运营得更久。我们保持精简，不像大公司那样雇用大量人员，因此无需承担庞大的薪资开支，公司也不太可能因内部权力斗争而关闭。我们能够在确保软件基础设施足够稳健的同时，避免浪费巨额服务器费用。
5. 你们提供支持吗？ 🔗
提供。如果您订阅 PRO 或 ENTERPRISE 方案，任何 API 相关问题都可以发送至 hello@listennotes.com。我们偶尔也会回答 FREE 用户的问题，但必须优先服务 PRO/ENTERPRISE 用户。
您无需像在其他公司那样辗转寻找敷衍的客服，而是会直接与亲手、用心打造这一切的 Listen Notes, Inc. 创始人兼 CEO沟通。
6. 我们会产生大量 API 请求。你们能支持这样的规模吗？ 🔗
目前已有公司通过 Listen API 每月发送数千万次请求。即使不增加服务器，我们也能轻松支持当前流量的至少十倍。
我们采用基础设施运维最佳实践，并配备完善的监控和告警。一旦 API 基础设施出现问题，我们可以尽快排查并修复。从系统性能和可用性来看，我们拥有相当不错的历史记录。
7. 我们可以在客户端（例如应用或浏览器中）缓存 API 响应吗？ 🔗
可以。我们的 API 使用条款（FREE 和 PRO 方案）允许您在客户端缓存响应数据；但除播客/episode id 和 pub_date 外，FREE 和 PRO 方案不允许在服务器端缓存。
换言之，服务器端（例如您自己的数据库）只能永久存储播客/episode id 和 pub_date。数据 API 普遍采用这种“禁止缓存”政策，例如 Google Maps API（可在页面中搜索“No Scraping”）。
对于播客的实际音频文件，您可以将其存储在服务器上并进行处理，例如制作音频片段或语音转文字。
如果订阅 ENTERPRISE 方案，则可以在服务器上缓存完整的响应数据。
8. 为什么 API 响应中的音频 URL 使用 listennotes.com 域名？ 🔗
首先说明：我们不会把音频存储在自己的服务器上。Podcast 创作者仍会获得准确的分析数据，例如听众的 IP 地址和 user-agent。
我们使用自己的 URL 包装实际 URL（HTTP 301），例如 audio.listennotes.com/e/p/997c4db8bd224df78f0716a3a8c05f5d。这是因为播客经常更换音频 URL，而我们希望帮助您和您的用户找到正确的地址。
为了优化性能，应用通常会在客户端缓存数据。应用可以缓存永久有效的 Listen Notes URL，而我们会在服务器端查找正确的音频 URL，并持续检查播客是否更改了音频地址。
9. 如果找不到某个播客怎么办？如果数据没有与 RSS 源同步（例如音频损坏或播客元数据不正确）怎么办？ 🔗
虽然我们的播客数据库非常全面，但仍可能未能及时收录某些新节目。这类似于您无法立刻在 Google 上找到新网站，因为爬虫发现并建立索引需要时间。在这种情况下，您可以帮助提交缺失的节目。
也可能是播客创作者更改了 RSS 源而我们尚未及时发现，或 RSS 源本身存在错误。这类似于从 Google 搜索结果中打开返回 404 或已经过时的网页；Google 也需要时间修复。您可以通过 hello@listennotes.com 报告元数据错误，我们会尽快修复（通常只需几分钟）。您也可以在自己的端上使用自助工具修复元数据错误，一起帮助维护数据 :)
10. 你们如何确保播客数据库保持最新？ 🔗
我们通过四种方式发现新的播客：
- 第一，全天候运行爬虫，在互联网上寻找公开可访问的播客；这与 Google 等搜索引擎发现新网站的方式类似。
- 第二，播客创作者会自行向 Listen Notes 提交新节目；我们每天都会收到数百个新提交。
- 第三，如果我们（Listen Notes 员工）发现缺失的播客，会手动将其加入数据库。此外，我们还运营热门的播客搜索网站 listennotes.com，每月有超过 2,000,000 名用户。任何用户都可以向 Listen Notes 提交缺失的节目，帮助数据库保持全面和最新。请注意，我们会人工审核每一项提交，并拒绝虚假播客（例如机器生成的音频）。
- 第四，我们与主要播客托管服务商合作；它们会集成我们的 播客 API，让创作者能够直接向 Listen Notes 提交新节目。
我们全天候检查所有播客的 RSS 源。对于近期有人收听的播客（根据网站和 API 流量判断），新单集会在一小时内加入数据库，通常只需 15 至 30 分钟。其他播客的新单集会在数小时内抓取，通常为 2 至 4 小时。
11. 如果我们违反 API 使用条款会怎样？ 🔗
如果违反 API 使用条款，您的账户将被暂停。您可以发送邮件至 hello@listennotes.com 提出申诉。
API 用户最常因以下两种情况被暂停：1. 创建多个账户来绕过 FREE 方案的配额限制，尤其是使用一次性电子邮箱；2. 在服务器端缓存大部分响应数据。请确保不要违反 API 使用条款。
12. 即使使用付费方案，也必须在应用中显示 Listen Notes 标志吗？ 🔗
是的。我们的 API 使用条款适用于所有 FREE/PRO API 用户。您只需在一个使用我们数据的界面上显示 Listen Notes 品牌标志，无需每个界面都显示。标志可以放在首屏以下，以免过多干扰用户。
无论您是个人开发者还是上市公司，我们都不会为任何 FREE/PRO API 用户提供例外。一次性的定制会增加我们的运维复杂度，并占用原本可用于改进核心产品的时间。
数据 API 要求标明来源是常见政策，例如 Google Places & Maps APIs。Uber 在应用中使用 Google Maps，应用里也有醒目的 Google 标志。
如果订阅 ENTERPRISE 方案，我们可以灵活调整标志要求。
13. 我们可以通过电话讨论合作吗？ 🔗
Listen API 按自助服务方式设计。如果您在几分钟内仍无法弄清 Listen API 能做什么以及如何使用，那是我们没有解释清楚。若有问题，请先通过电子邮件联系：hello@listennotes.com。
通过电子邮件获得我们详尽答复的速度，会比安排电话会议快得多。
14. 我可以在无代码平台上使用 Listen API 吗？ 🔗
15. 你们是否提供用于播客 API 的各编程语言专用库？ 🔗
16. Listen Notes 会收集 API 用户的哪些信息？ 🔗
我们只收集直接向服务器发送 API 请求的设备所需的最少信息，包括：1）设备的 IP 地址；2）user-agent；3）API 请求的端点和参数。这基本上就是 Nginx 访问日志中的一行记录，仅此而已。
例如，某位开发者使用我们的 API 构建了一款播客应用，许多终端用户通过该应用收听播客。通常，API 请求来自开发者的服务器，而不是播客应用本身；也就是说，开发者的服务器充当播客应用与 Listen API 之间的代理。因此，我们只会记录：1）发送 API 请求的开发者服务器 IP 地址；2）来自开发者服务器的 user-agent（例如 python-requests）；3）API 请求的端点和参数。除此之外，我们不了解该播客应用的终端用户。
17. Listen API 有速率限制吗（例如每秒最多 N 个请求）？ 🔗
有。我们会为 API 端点设置合理的速率限制。如果正确使用 API，您甚至可能不会察觉这些限制的存在。
世界上任何严肃的 REST API 都必须设置速率限制，可以搜索 Google “api rate limit” 了解详情。没有速率限制的 API 很容易遭受 DDoS。例如，程序员可能会通过紧密循环（甚至无限循环）在短时间内发送大量 API 请求。根据我们自 2017 年运营 Listen API 的经验，这类情况比预想中更常见。程序员也是人，人都会犯错。我们不希望某个不当用户拖垮整个系统并影响其他 API 用户。
Listen API 的 FREE 方案速率限制较低，PRO 方案较高，ENTERPRISE 方案最高。不同端点的限制也不同，因为有些端点比其他端点需要更多计算资源。新 API 用户一开始会获得相对较低的速率限制，之后会逐步提高。
18. 你们会处理与 DMCA、GDPR 等法律相关的播客删除请求吗？ 🔗
会。我们会处理内容删除请求。详情请参阅：
您可以通过以下 API 端点，将用户的内容删除请求转交给 Listen Notes：DELETE /podcasts/{id}（也可以直接让用户联系 hello@listennotes.com）。