ブログ

著者 javinfo team

JAVメタデータAPI: 5つのスクレイパーの代わりにエンドポイント1つ

あらゆるJAVメタデータソースは腐っていくスクレイパーだ。javinfo はホスト型APIがひとつ。DVDコードを送れば正規化されたメタデータが返り、子守りするスクレイパーはない。

JAVメタデータをアプリに入れたいなら、誰もが歩む道はこうです。ソースを見つけ、スクレイパーを書き、スクレイパーが壊れ、抜けを埋めるために2つ目のソース用にもうひとつ書き、半年後にはタイトルと発売日とカバー画像を手に入れるためだけに、5つの脆い統合を保守しているのです。

公開された安定したJAVメタデータAPIは、世の中に存在しません。最初からありませんでした。javinfo はそのひとつです。それが、これが存在する理由のすべてです。

なぜ「JAVメタデータAPI」はこれほど見つけにくいのか

データは本物で、よく構造化されています。問題はアクセスです。あなたが手を伸ばすであろうあらゆるソースは、契約を備えたAPIではなく、防御を備えたウェブサイトなのです。

つまり、GitHubで見つかる「API」は常にスクレイパーであり、スクレイパーはソースサイトが抱えるあらゆる問題を受け継ぎます。クラス名のリネームが、変更履歴も警告もなくパーサーを壊します。Cloudflare のチャレンジとリージョンブロックのせいで、ヘッドレスブラウザのバイパスとプロキシも運用することになります。そして各ソースが異なる形を返すので、抜けを埋めるには3つや4つのスキーマを自分で正規化する必要があります。

あなたが保守するのはひとつの統合ではありません。スクレイパーと、バイパスと、プロキシと、深夜2時のためのポケベルを保守することになるのです。

javinfo が代わりにすること

エンドポイントはひとつ。コードを送れば、正規化された結果がひとつ返り、どのソースが応答しても同じフィールドの形になります。

Look up a code
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" }'
Response
{
"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 形にマッピングされます。dvdIdtitleEn/titleJareleaseDateruntimeMinsmakerslabelseriesactressesjacketFullUrl などです。ソースをまたいで result.video.* を同じように読めます。スクレイピングも、Cloudflare との戦いも、ジオブロックの回避策も私たちが引き受けるので、あなたはやらずに済みます。これが、全体が築かれている プロバイダー非依存の設計 です。

プロバイダー

javinfo に最初のマッチを選ばせるか、providers でソースを固定してください。

ミスした場合、またはすべてのアップストリームがタイムアウトした場合は 504 が返ります。これはたいてい、そのコードがインデックスされていないというだけの意味です。レスポンスはサーバー側でキャッシュされるので、繰り返しの照会は高速です。

はじめる

認証、レート制限、プランは RapidAPI にあります。無料ティアでは r18 のメタデータを1日100リクエストまで利用でき、Pro では javdbmissav のプロバイダー、そのダウンロードリンクとストリームリンク、そして1日1,000リクエストが追加されます。Dockerも、FlareSolverr も、日本のVPNも、更新するクッキーも不要です。1分で動かせます。