如果你想在应用里用上 JAV 元数据，下面就是每个人都走过的路。你找到一个数据源，写一个抓取工具，抓取工具坏了，你又写一个去抓第二个数据源来填补空缺，半年后你为了拿到一个标题、一个发行日期和一张封面图，维护着五个脆弱的集成。
外面并不存在一个公开、稳定的 JAV 元数据 API。从来就没有过。javinfo 就是这样一个。这正是它存在的全部理由。
为什么”JAV 元数据 API”如此难找
数据是真实存在且结构良好的。问题出在访问上。每一个你会去找的数据源都是一个带防御的网站，而不是一个带契约的 API：
- DMM / FANZA 拥有大部分目录，并且对地球上大部分地区进行地理封锁。有一个联盟 API，但文档只有日语版，而且藏在相同的封锁背后。
- JavDB 根本没有官方 API，只有顶着这个名字的社区抓取工具，其中大多数还需要 FlareSolverr 才能绕过 Cloudflare。
- JavBus、JavLibrary、R18 是同样的故事：自托管的抓取工具和 Docker 容器，解析器绑定在会无通知更改的 HTML 上。
所以你在 GitHub 上找到的”API”永远是一个抓取工具，而抓取工具继承了源站点的每一个问题。一次类名重命名就会搞坏你的解析器，没有变更日志，没有警告。Cloudflare 的挑战和区域封锁意味着你还得运行一个无头浏览器绕过方案和一个代理。而且因为每个数据源返回的结构都不一样，填补空缺意味着你得自己去规范化三四套结构。
你维护的并不是一个集成。你维护的是一个抓取工具、一个绕过方案、一个代理，以及一个应对凌晨两点的传呼机。
javinfo 做的是什么
一个端点。发送一个番号，拿回一个规范化的结果，无论哪个数据源做出了响应，字段结构都相同。
curl -X POST 'https://javinfo-search.p.rapidapi.com/search' \ -H 'Content-Type: application/json' \ -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \ -H 'X-RapidAPI-Host: javinfo-search.p.rapidapi.com' \ -d '{ "q": "SSIS-001" }'{ "result": { "q": "SSIS-001", "source": "r18", "video": { "dvdId": "SSIS-001", "titleEn": "Newcomer NO.1 STYLE ...", "releaseDate": "2020-07-07", "runtimeMins": 120, "makers": ["S1 NO.1 STYLE"], "actresses": [{ "name": "Example Actress", "image": "https://pics.dmm.co.jp/..." }] } }, "latencyMs": 142, "cached": false}每个数据源都映射到相同的基础 video 结构：dvdId、titleEn/titleJa、releaseDate、runtimeMins、makers、label、series、actresses、jacketFullUrl 等等。你在各个数据源之间都以相同的方式读取 result.video.*。我们替你打理抓取、Cloudflare 的缠斗以及地理封锁的绕过方案。这就是整个项目所基于的与数据源无关的设计。
各个数据源
让 javinfo 挑选第一个匹配项，或者用 providers 指定一个数据源：
r18返回双语元数据（标题、出演阵容、制作商、厂牌、系列、封面），外加女优资料照片和样片/画廊 URL。所有套餐均可用。javdb新增一个extra.downloadLinks数组，包含磁力链接和下载链接，正是抓取工具们争抢的东西。Pro 套餐。missav新增一个extra.streams对象，包含 HLS 播放列表 URL（.m3u8）以及各分辨率的变体。Pro 套餐。javlibrary、javdatabase即将推出。
未命中时，或者如果所有上游都超时，你会得到一个 504，这通常只是意味着该番号尚未被索引。响应在服务端缓存，所以重复查询很快。
开始
鉴权、速率限制和套餐都在 RapidAPI 上。免费套餐为你提供 r18 元数据，每天 100 次请求；Pro 套餐新增 javdb 和 missav 数据源、它们的下载和流媒体链接，以及每天 1,000 次请求。不需要 Docker，不需要 FlareSolverr，不需要日本 VPN，不需要刷新 cookie。你可以在一分钟内跑起来。