最大的 API 列表,但故事不止 star 数

public-apis/public-apis 是 GitHub 上 star 数最高的资源型仓库之一。它是一个人工整理的 public API 列表,按领域分类,并用几个字段标出 authentication、HTTPS 和 CORS 支持情况。如果你在做原型,需要 weather API、open data、movie database、currency feed、test data、government endpoint 或其他公开接口,这类列表通常会最先被搜到。

它也很好地说明了一个问题:star 数不等于信任。截至 2026-06,public-apis/public-apis 有 440,789 star、48,300 fork 和 1,363 个开放 issue。它使用 MIT 许可证,GitHub 标记的主要语言是 Python,最近一次 push 是 2026-06-07。当前 README 顶部先展示 APILayer 推广和 APILayer 产品链接,然后才是 public API index。长期开放的 #3104 记录了社区对 maintainer access、商业影响和项目治理的担忧。另一个开放 issue #3484 则把用户指向一个活跃社区 fork。

这不代表这个列表没用。它仍然是 public API 发现的重要入口。只是使用它时要带上背景,尤其当你关心 freshness、治理或机器可读数据时,不要只依赖这一个仓库。

这个列表实际提供什么

核心资产是一个很大的 README index。分类包括 Animals、Anime、Anti-Malware、Art and Design、Authentication and Authorization、Blockchain、Books、Business、Calendar、Cloud Storage and File Sharing、Continuous Integration、Cryptocurrency、Currency Exchange、Data Validation、Development、Dictionaries、Documents and Productivity、Email、Entertainment、Environment、Events、Finance、Food and Drink、Games and Comics、Geocoding、Government、Health、Jobs、Machine Learning、Music、News、Open Data、Open Source Projects、Programming、Science and Math、Security、Shopping、Social、Sports and Fitness、Test Data、Transportation、Video、Weather 等。

每个 API 条目都很简单:名称、描述、认证要求、HTTPS 状态和 CORS 状态。这足够做第一轮筛选。如果 authentication 是 No,HTTPS 是 Yes,通常可以很快打开文档试用。如果需要 apiKey 或 OAuth,就要先读 provider docs。如果 CORS 是 No 或 Unknown,它可能只适合服务端调用。

这对产品灵感和早期调研很有用。但它不能替代最终集成检查。API 条款、quota、认证方式、域名归属和响应格式都会变。把 public-apis 当地图,真正接入前仍要直接验证服务商文档。

贡献规则体现了原本的质量线

CONTRIBUTING 文件比当前 README 更能说明项目原本的质量线。它明确说这个列表不是 marketing tool,也要求贡献者避免提交主要是付费方案的公司 API。它还要求被提交的 API 至少有完整免费访问或 free tier,且不能依赖购买设备或服务。

格式规则也很实用。条目需要在分类内按字母排序,描述要短,一个 PR 只加一个 API,名称不要以 API 结尾,提交前要搜索重复项。Auth 字段有固定取值,CORS 字段只能是 Yes、No 或 Unknown。这些规则解释了为什么这个列表曾经好用:它不是单纯堆链接,而是有一个轻量 schema,方便人快速扫。

当前仓库仍保留了这套结构。问题在于 review 流程是否还能跟上提交量和治理争议。

APILayer 与 fork 提醒

#3104 是理解这个仓库最重要的背景。它在 2022 年打开,到 2026 年仍保持 open。早期评论来自维护者,提到 maintainer access 被降低、APILayer branding 变化,以及商业 API 被推到普通 alphabetical rule 前面的担忧。后续讨论包括 fork、项目 stewardship,以及活跃维护者是否有足够控制权来保护项目。

#3484 给用户的信号更短:建议使用 public-apis-dev/public-apis。GitHub 现在会把这个路径解析到 marcelscruz/public-apis,后者把自己描述为面向开发者的 collaborative public API list。截至 2026-06,marcelscruz/public-apis 有 9,093 star、933 fork、MIT 许可证,主页是 https://publicapis.dev。

实际结论很简单。如果你只需要一个巨大的历史列表,public-apis/public-apis 仍值得查。如果你关心当前社区维护状态,应同时比较 marcelscruz/public-apis。

近期活动与 spam 信号

这个仓库并没有完全冻结。2026 年 6 月的近期 pull request 仍在添加 Hlido、Pulse、OpenChainBench、Cohere、LinkPeek、Geo Toolkit、currency data additions、Extracto 等 API。近期 issue 也包括新增 API、重复链接修复和 README 表格格式修复。

同时,开放 PR 列表里能看到重复 spam comments,内容是推销无关 API key 或 AI copy 服务。这个信号很重要,因为公开目录加上轻量提交,天然会吸引低质量推广。原始贡献规则就是为了避免这种 marketing drift。严肃使用时,不要默认每个可见条目都有同等 review 深度,应该检查最近 merged changes。

开放 issue 数量也值得注意。1,363 个开放 issue 对一个 curated list 来说很高。部分来自知名仓库的正常流量,部分说明 triage 和维护一直是这个项目的难点。

和其他 API 目录怎么比

marcelscruz/public-apis 是最直接的比较对象,因为 #3484 指向的社区 fork 当前解析到这里。它 star 少得多,但当前身份更清楚,2026 年 6 月仍有活跃 push,并有 publicapis.dev 网站。如果你要选一个当前 API discovery 来源,应该把它和原仓一起看。

public-api-lists/public-api-lists 是另一个列表型替代。截至 2026-06,它有 14,717 star、1,542 fork,描述是覆盖 48 个分类的 free public API curated list,并提供 free JSON API。这个 JSON API 角度适合想做工具的人,比人工读 README 更方便。

APIs-guru/openapi-directory 则是另一类东西。它是 REST API definitions 目录,格式是 OpenAPI 2.0 和 3.x,许可证是 CC0-1.0,主页是 apis.guru。它 star 少一些,但更适合 code generation、client、validation 和 API metadata workflow。

sindresorhus/awesome 更宽泛。它收录的是各种 awesome list,本身并非 API list。当你还在探索一个领域时看它。当你已经确定要找 API 时,再看 public-apis 或这些替代目录。

什么时候该用 public-apis

当你想快速扫一个分类里可能有哪些 public API 时,public-apis/public-apis 仍然有价值。它适合 hackathon、prototype、示例、教学和早期产品调研。它也能帮你发现自己没想到要搜的分类,比如 test data、geocoding、dictionaries、patent data 或 science APIs。

不要把它当生产依赖。真正集成任何 listed API 前,都要验证 provider domain、documentation、license 或 terms、authentication、pricing、uptime、quota、CORS behavior 和 response examples。如果你做纯浏览器应用,请自己测 CORS。如果你做商业产品,请直接读 provider terms。

如果你要做数据管线或开发者工具,尽量选择机器可读来源。README table 适合人读,但对自动化很脆弱。

Star 曲线怎么看

采样 star history 显示,public-apis 从 2016 年的小列表成长为 GitHub 上最大的开发者资源仓库之一。由于这个仓库 star 数很大,GitHub stargazer 分页成本高,曲线是抽样结果,不要过度解读短期点位间距。真正耐久的信号是:API discovery 多年来一直是开发者的常见需求。

这个项目还说明了另一件事:热门列表会变成基础设施。当一个列表有足够流量后,ownership、sponsorship、review rules 和 spam control 都会变成产品问题,不再是细枝末节。

相关阅读

更宽的开发者资源发现可以看 sindresorhus/awesome。如果你想找会用到 public API 的项目练习,可以看 codecrafters-io/build-your-own-x。另一个教育资源目录视角可以看 freeCodeCamp/freeCodeCamp。更大的发现入口是 GitHub trending repositories。

FAQ

public-apis/public-apis 是什么? 它是按分类整理的 public API 大列表,字段包括 authentication、HTTPS 和 CORS。

public-apis 还在维护吗? 仓库仍有 push 和 pull request,但也有很高的开放 issue 数量和长期治理争议。依赖前要看近期 merged work。

README 为什么有 APILayer? 当前 README 顶部包含 APILayer 推广。#3104 记录了社区对 APILayer 影响和 maintainer access 的担忧。

大家说的 active fork 是哪个? #3484 指向 public-apis-dev/public-apis,这个路径现在解析到 marcelscruz/public-apis。

列表里的 API 可以直接生产使用吗? 不建议直接信任。它是 discovery tool,不是对 terms、uptime、pricing、auth、CORS 或 data quality 的保证。生产接入前必须直接验证服务商文档。