博客

作者 javinfo team

JAV 元数据 API:用一个端点取代五个抓取工具

每一个 JAV 元数据数据源都是会腐烂的抓取工具。javinfo 是一个托管 API —— 发送一个 DVD 番号,拿回规范化的元数据,没有需要看管的抓取工具。

如果你想在应用里用上 JAV 元数据,下面就是每个人都走过的路。你找到一个数据源,写一个抓取工具,抓取工具坏了,你又写一个去抓第二个数据源来填补空缺,半年后你为了拿到一个标题、一个发行日期和一张封面图,维护着五个脆弱的集成。

外面并不存在一个公开、稳定的 JAV 元数据 API。从来就没有过。javinfo 就是这样一个。这正是它存在的全部理由。

为什么“JAV 元数据 API”如此难找

数据是真实存在且结构良好的。问题出在访问上。每一个你会去找的数据源都是一个带防御的网站,而不是一个带契约的 API:

所以你在 GitHub 上找到的“API”永远是一个抓取工具,而抓取工具继承了源站点的每一个问题。一次类名重命名就会搞坏你的解析器,没有变更日志,没有警告。Cloudflare 的挑战和区域封锁意味着你还得运行一个无头浏览器绕过方案和一个代理。而且因为每个数据源返回的结构都不一样,填补空缺意味着你得自己去规范化三四套结构。

你维护的并不是一个集成。你维护的是一个抓取工具、一个绕过方案、一个代理,以及一个应对凌晨两点的传呼机。

javinfo 做的是什么

一个端点。发送一个番号,拿回一个规范化的结果,无论哪个数据源做出了响应,字段结构都相同。

Look up a code
curl -X POST "https://api.javinfo.dev/movie" \
-H "x-javinfo-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{ "q": "SSIS-001" }'
Response
{
"q": "SSIS-001",
"source": "fanza",
"result": {
"dvdId": "SSIS-001",
"titleEn": "Newcomer NO.1 STYLE ...",
"releaseDate": "2020-07-07",
"runtimeMins": 120,
"makers": ["S1 NO.1 STYLE"],
"actresses": ["Example Actress"],
"jacketFullUrl": "https://pics.dmm.co.jp/digital/video/ssis00001/ssis00001pl.jpg"
}
}

每个数据源都映射到相同的基础 result 结构:dvdIdtitleEn/titleJareleaseDateruntimeMinsmakerslabelseriesactressesjacketFullUrl 等等。你在各个数据源之间都以相同的方式读取 result.*。我们替你打理抓取、Cloudflare 的缠斗以及地理封锁的绕过方案。这就是整个项目所基于的与数据源无关的设计。若要进行宽泛搜索,/query 端点会返回一个匹配列表,而不是单个最佳结果。

各个数据源

让 javinfo 挑选第一个匹配项,或者用 providers 指定一个数据源:

未命中时,或者如果所有上游都超时,你会得到一个 404,这通常只是意味着该番号尚未被索引。响应在服务端缓存,所以重复查询很快。

开始

app.javinfo.dev 注册、获取密钥,并通过 x-javinfo-key 请求头传入(也可在 RapidAPI 上使用)。所有数据源在每个请求上都返回完整数据,没有任何门槛限制 —— 按用量计费:每个成功的 /movie 结果收费 $0.0005,/query 收费 $0.0002,查询失败不计费。用 USDC 充值,按 1:1 到账,单次充值满 $50 还会获得 5–50% 的随机赠送;新用户注册即可获得 100+ 次免费查询,无需信用卡。不需要 Docker,不需要 FlareSolverr,不需要日本 VPN,不需要刷新 cookie。你可以在一分钟内跑起来。