Listen API 常問問題
API 版本：V2 ·
PodcastAPI.com
解答有關 Listen API 的常見問題。
請閱讀 https://www.podcastapi.com/llms-full.txt，這樣我就可以詢問有關 Listen Notes Podcast API 的問題。
1. 為什麼要使用 Listen API？相比 iTunes API，它有什麼優勢？ 🔗
您始終可以選擇其他方案：自行建置並維護 Podcast 資料庫，或使用網際網路上的其他 Podcast API。
為了方便您評估 Listen API，我們提供透明、簡潔的定價模式，以及涵蓋所有 API 端點和 JSON 回應範例的完整說明檔案。
試用 Listen API 非常簡單。您無需與銷售人員溝通，也不必「申請示範」。只需訂閱無需信用卡資訊的 FREE 方案，即可開始使用 Listen API。
如果您訂閱 PRO 或 ENTERPRISE 方案，遇到任何問題都可以傳送郵件至 hello@listennotes.com，很快就能直接得到 Listen Notes 創始人兼 CEO的回覆。
Apple 的 iTunes API 怎麼樣？建議您閱讀其說明檔案並親自試用。您會發現它可能並不適合您的需求，因為：
- 它沒有提供足夠的 API 端點和結構化回應資料來建置某些基本功能（例如搜尋所有單集、播放音訊、策劃播放清單等）；閱讀說明檔案幾分鐘即可瞭解；
- Podcast 搜尋結果數量不多，排序效果也不理想；
- 其服務條款可能不允許您實現想做的事情；同樣，閱讀說明檔案幾分鐘即可瞭解；
- 該 API 很可能不是 Apple Inc. 的重要產品，因此未必由其最優秀的員工持續維護和改進；
- 使用企業 API 時，真人（例如支援工程師）提供的客戶支援通常是服務的一部分；而要及時從 Apple Inc. 員工那裡得到有用回覆並不容易。
這篇部落格文章也許對您有幫助：如何評估第三方 RESTful API？
2. 建置一個 Podcast 資料庫到底有多難？ 🔗
建置一個像樣的 Podcast 資料庫是一項持續投入。技術上並不困難，但建置和維護都需要時間和資金，包括伺服器成本和工程師薪資等。就像擁有汽車或房屋一樣，購買時的一次性支出遠低於長期維護成本，其中包括稅費、保險、意外維修，最重要的還有您的時間。
自行建置和維護 Podcast 資料庫前，需要考慮以下問題：
- 網際網路上至少有 3,831,426 個 Podcast 和 196,768,984 個單集，而且內容規模增長越來越快。您需要自行託管資料並確保資料保持最新。
- 在 3,831,426 個 Podcast 和 196,768,984 個單集的規模下，RSS 來源和音訊 URL 的變更比想象中更頻繁。您需要全天候投入自動化工具和人工流程來清理資料；這些工作不可或缺，卻不會被使用者直接看到。
- 如果需要按關鍵字搜尋 3,831,426 個 Podcast 和 196,768,984 個單集，就必須自行建置搜尋引擎。搜尋引擎的介面看似簡單，後端基礎設施卻極其複雜。Google 這個「簡單網站」在 2022 年擁有 17.5 萬名全職員工和數十萬名承包商，自有其原因。
- 網際網路上有大量虛假 Podcast，例如機器生成的音訊。黑帽 SEO 從業者會為建立連結製造許多並非供真人收聽的虛假節目。您必須同時部署自動化和人工流程，避免把這些內容收入資料庫。有趣的是，Google 擁有專門的網頁垃圾內容團隊；Listen Notes 也投入了大量資源處理虛假 Podcast。
- 如果資料庫和搜尋引擎需要全天候執行，還必須投入精力避免伺服器中斷。
- 一名合格的全職軟體工程師需要多少薪資？與其支付幾名內部工程師的工資，您是否更願意為第三方雲服務（例如我們的 API）付費？
坦率地說，自行建置和維護 Podcast 資料庫最昂貴的部分是機會成本。這關乎取捨：用於建置資料庫的時間，就無法用於開發您的 App 或網站。
使用 Listen API 可以讓您立即開始專案中最令人興奮的部分。此外，我們運營著熱門的 Podcast 搜尋網站 listennotes.com，每月有超過 2,000,000 名使用者；這些使用者在保持資料庫更新方面發揮著重要作用。例如，他們會幫助提交缺失的 Podcast並修正錯誤資料。借助全球使用者全天候的幫助，我們得以維護一個高品質的 Podcast 資料庫。
3. 你們是否在積極維護 API？未來會繼續維護嗎？ 🔗
是的，而且會繼續。
Listen API 為面向使用者的網站 ListenNotes.com 提供支援，也會受益於 ListenNotes.com 的大多數後端改進。
我們從 2017 年運營至今，並計劃長期繼續運營。
4. 如果我們使用 Listen API，而它以後停止服務怎麼辦？ 🔗
您的擔憂很合理。我們都知道，沒有任何在線服務或公司能永遠存在。例如，Google 也終止過許多自己的產品。
如果我們決定關閉 Listen API，會至少提前 12 周通知您；屆時您還可以用合理的低價購買最新的完整資料庫匯出（所有 Podcast 和所有單集）。
Listen Notes 很可能比許多資金充足的初創公司甚至上市公司運營得更久。我們保持精簡，不像大公司那樣雇用大量人員，因此無需承擔龐大的薪資開支，公司也不太可能因內部權力鬥爭而關閉。我們能夠在確保軟體基礎設施足夠穩健的同時，避免浪費巨額伺服器費用。
5. 你們提供支援嗎？ 🔗
提供。如果您訂閱 PRO 或 ENTERPRISE 方案，任何 API 相關問題都可以傳送至 hello@listennotes.com。我們偶爾也會回答 FREE 使用者的問題，但必須優先服務 PRO/ENTERPRISE 使用者。
您無需像在其他公司那樣輾轉尋找敷衍的客服，而是會直接與親手、用心打造這一切的 Listen Notes, Inc. 創始人兼 CEO溝通。
6. 我們會產生大量 API 請求。你們能支援這樣的規模嗎？ 🔗
目前已有公司透過 Listen API 每月傳送數千萬次請求。即使不增加伺服器，我們也能輕鬆支援目前流量的至少十倍。
我們採用基礎設施運維最佳實踐，並配備完善的監控和告警。一旦 API 基礎設施出現問題，我們可以盡快排查並修復。從系統效能和可用性來看，我們擁有相當不錯的歷史記錄。
7. 我們可以在客戶端（例如 App 或瀏覽器中）快取 API 回應嗎？ 🔗
可以。我們的 API 使用條款（FREE 和 PRO 方案）允許您在客戶端快取回應資料；但除 Podcast/episode id 和 pub_date 外，FREE 和 PRO 方案不允許在伺服器端快取。
換言之，伺服器端（例如您自己的資料庫）只能永久儲存 Podcast/episode id 和 pub_date。資料 API 普遍採用這種「禁止快取」政策，例如 Google Maps API（可在頁面中搜尋「No Scraping」）。
對於 Podcast 的實際音訊檔案，您可以將其儲存在伺服器上並進行處理，例如製作音訊片段或語音轉文字。
如果訂閱 ENTERPRISE 方案，則可以在伺服器上快取完整的回應資料。
8. 為什麼 API 回應中的音訊 URL 使用 listennotes.com 網域？ 🔗
首先說明：我們不會把音訊儲存在自己的伺服器上。Podcast 創作者仍會獲得準確的分析資料，例如聽眾的 IP 地址和 user-agent。
我們使用自己的 URL 包裝實際 URL（HTTP 301），例如 audio.listennotes.com/e/p/997c4db8bd224df78f0716a3a8c05f5d。這是因為 Podcast 經常更換音訊 URL，而我們希望幫助您和您的使用者找到正確的地址。
為了最佳化效能，App 通常會在客戶端快取資料。App 可以快取永久有效的 Listen Notes URL，而我們會在伺服器端尋找正確的音訊 URL，並持續檢查 Podcast 是否更改了音訊地址。
9. 如果找不到某個 Podcast 怎麼辦？如果資料沒有與 RSS 來源同步（例如音訊損壞或 Podcast 中繼資料不正確）怎麼辦？ 🔗
雖然我們的 Podcast 資料庫非常全面，但仍可能未能及時收錄某些新節目。這類似於您無法立刻在 Google 上找到新網站，因為爬蟲發現並建立索引需要時間。在這種情況下，您可以幫助提交缺失的節目。
也可能是 Podcast 創作者更改了 RSS 來源而我們尚未及時發現，或 RSS 來源本身存在錯誤。這類似於從 Google 搜尋結果中打開返回 404 或已經過時的網頁；Google 也需要時間修復。您可以透過 hello@listennotes.com 報告中繼資料錯誤，我們會盡快修復（通常只需幾分鐘）。您也可以在自己的端上使用自助工具修復中繼資料錯誤，一起幫助維護資料 :)
10. 你們如何確保 Podcast 資料庫保持最新？ 🔗
我們透過四種方式發現新的 Podcast：
- 第一，全天候執行爬蟲，在網際網路上尋找公開可存取的 Podcast；這與 Google 等搜尋引擎發現新網站的方式類似。
- 第二，Podcast 創作者會自行向 Listen Notes 提交新節目；我們每天都會收到數百個新提交。
- 第三，如果我們（Listen Notes 員工）發現缺失的 Podcast，會手動將其加入資料庫。此外，我們還運營熱門的 Podcast 搜尋網站 listennotes.com，每月有超過 2,000,000 名使用者。任何使用者都可以向 Listen Notes 提交缺失的節目，幫助資料庫保持全面和最新。請注意，我們會人工審核每一項提交，並拒絕虛假 Podcast（例如機器生成的音訊）。
- 第四，我們與主要 Podcast 託管服務商合作；它們會整合我們的 Podcast API，讓創作者能夠直接向 Listen Notes 提交新節目。
我們全天候檢查所有 Podcast 的 RSS 來源。對於近期有人收聽的 Podcast（根據網站和 API 流量判斷），新單集會在一小時內加入資料庫，通常只需 15 至 30 分鐘。其他 Podcast 的新單集會在數小時內抓取，通常為 2 至 4 小時。
11. 如果我們違反 API 使用條款會怎樣？ 🔗
如果違反 API 使用條款，您的帳戶將被暫停。您可以傳送郵件至 hello@listennotes.com 提出申訴。
API 使用者最常因以下兩種情況被暫停：1. 建立多個帳戶來繞過 FREE 方案的配額限制，尤其是使用一次性電子郵件；2. 在伺服器端快取大部分回應資料。請確保不要違反 API 使用條款。
12. 即使使用付費方案，也必須在 App 中顯示 Listen Notes 標誌嗎？ 🔗
是的。我們的 API 使用條款適用於所有 FREE/PRO API 使用者。您只需在一個使用我們資料的介面上顯示 Listen Notes 品牌標誌，無需每個介面都顯示。標誌可以放在第一屏以下，以免過多干擾使用者。
無論您是個人開發者還是上市公司，我們都不會為任何 FREE/PRO API 使用者提供例外。一次性的客製化會增加我們的運維複雜度，並佔用原本可用於改進核心產品的時間。
資料 API 要求標明來源是常見政策，例如 Google Places & Maps APIs。Uber 在 App 中使用 Google Maps，App 裡也有醒目的 Google 標誌。
如果訂閱 ENTERPRISE 方案，我們可以靈活調整標誌要求。
13. 我們可以透過電話討論合作嗎？ 🔗
Listen API 按自助服務方式設計。如果您在幾分鐘內仍無法弄清 Listen API 能做什麼以及如何使用，那是我們沒有解釋清楚。若有問題，請先透過電子郵件聯絡：hello@listennotes.com。
透過電子郵件獲得我們詳盡回覆的速度，會比安排電話會議快得多。
14. 我可以在無程式碼平台上使用 Listen API 嗎？ 🔗
15. 你們是否提供用於 Podcast API 的各編程語言專用庫？ 🔗
16. Listen Notes 會收集 API 使用者的哪些資訊？ 🔗
我們只收集直接向伺服器傳送 API 請求的設備所需的最少資訊，包括：1）設備的 IP 地址；2）user-agent；3）API 請求的端點和參數。這基本上就是 Nginx 存取日誌中的一行記錄，僅此而已。
例如，某位開發者使用我們的 API 建置了一款 Podcast App，許多終端使用者透過該 App 收聽 Podcast。通常，API 請求來自開發者的伺服器，而不是 Podcast App 本身；也就是說，開發者的伺服器充當 Podcast App 與 Listen API 之間的代理。因此，我們只會記錄：1）傳送 API 請求的開發者伺服器 IP 地址；2）來自開發者伺服器的 user-agent（例如 python-requests）；3）API 請求的端點和參數。除此之外，我們不瞭解該 Podcast App 的終端使用者。
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 等法律相關的 Podcast 刪除請求嗎？ 🔗
會。我們會處理內容刪除請求。詳情請參閱：
您可以透過以下 API 端點，將使用者的內容刪除請求轉交給 Listen Notes：DELETE /podcasts/{id}（也可以直接讓使用者聯絡 hello@listennotes.com）。