ForHosting KIT · サイト取得・監視

URLからAPIバージョニング方式を検出

パスがv1で始まるアドレスはパス型で、バージョンは1、位置は/v1です。アドレスを貼り付けるだけで、バージョンがパスにあるか、疑問符の後ろにあるか、ヘッダーだけかが分かり、ゲートウェイや資料づくりに役立ちます。ブラウザで無料で使えます。

無料
ブラウザで動作
登録不要
データは端末の外に出ません

無料で実行 API仕様を見る

ご利用方法ウェブAPIメールTelegramアプリ近日

計算例

入力した場合

Webアドレス: https://api.example.com/v1/users

結果

スキーム: path_based
バージョン: 1
生のバージョン: v1
場所: /v1

パス区切りの /v2/、クエリ文字列の ?バージョンがパスまたはクエリに現れる場合は抽出し、生トークンと一致箇所とともに返します。

Webサービスがバージョンを置く3つの場所

Webサービスがバージョンを示す方法はいくつかあります。最もよく見かけるのは、v2のようにスラッシュで区切ったパスの一部に入れる方法です。次に、疑問符の後ろにキーを置き、そこに2などの番号を入れる方法があります。3つ目はアドレスには何も入れず、バージョンをヘッダーで別に送る方法です。完全なアドレスを貼り付けると、どの方式かを判定し、バージョンが見えていればその値と見つかった位置を示します。パスがv1で始まり、その後にusersが続くアドレスなら、パス型、バージョン1、元の表記v1、位置/v1という結果になります。

判定で確かめることと、決してしないこと

受け付けるのは、httpまたはhttpsで始まる完全なアドレスだけで、それ以外は推測せずに受け付けません。疑問符の後ろのキーは大文字と小文字を区別せずに照合し、決まった優先順の一覧で値のある最初のキーを採用するため、項目の順番で答えは変わりません。v2と書かれたバージョンは2に整えますが、1.0.0はそのままで、betaのような語や2024-01-01のような日付も書かれたとおりに残します。サービスに接続することも、ホスト名だけからバージョンを作り出すこともないので、同じアドレスならいつも同じ答えになります。

よくある質問

パス型バージョニングとは何ですか？

v に続く数値バージョン（v1、v2.0）に一致するパス区切り、または version/1 や versions/2.0 の形です。

アドレスにバージョンが見つからないとはどういう意味ですか？

パスにも疑問符の後ろにもバージョンの印がなく、ヘッダー型と判定されたという意味です。こうしたサービスは、通常ヘッダーでバージョンを受け取るか、アドレスにバージョンを含めていません。

疑問符の後ろの項目の順番で結果は変わりますか？

変わりません。キーは大文字と小文字を区別せずに照合し、決まった優先順の一覧で値のある最初のキーを採用するため、並び順が違っても同じ答えになります。

v2や1.0.0のような書き方はどう扱われますか？

残りが数字と点だけなら先頭のvを外すので、v2は2になり、1.0.0はそのままです。betaのような語や2024-01-01のような日付は、書かれたとおりに残します。

貼り付けたアドレスにアクセスしますか？

しません。アドレスの文字を読むだけで、サービスには一切接続しません。ホスト名だけからバージョンを推測することもないので、印のないアドレスはそのまま印なしとして示します。

開発者向け — APIアクセス

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

エンドポイント

POSThttps://api.kit.forhosting.com/dev/api-versioning-scheme-detect

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

お使いのスタックから呼び出す

curl -X POST https://api.kit.forhosting.com/dev/api-versioning-scheme-detect \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://api.example.com/v1/users"}'

const res = await fetch("https://api.kit.forhosting.com/dev/api-versioning-scheme-detect", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "url": "https://api.example.com/v1/users"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/api-versioning-scheme-detect",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "url": "https://api.example.com/v1/users"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/api-versioning-scheme-detect", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"url":"https://api.example.com/v1/users"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"url":"https://api.example.com/v1/users"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/api-versioning-scheme-detect", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

リクエスト例

{
  "url": "https://api.example.com/v1/users"
}

レスポンス例

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.api_versioning_scheme_detect",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

料金

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

エラー

HTTP	コード	意味
`401`	`unauthorized`	APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
`402`	`insufficient_balance`	残高が不足しています。チャージ後に再度お試しください。
`404`	`unknown_type`	指定されたタスクタイプは存在しません。タイプ名を確認してください。
`429`	`rate_limited`	リクエストが多すぎます。しばらく待ってから再度お試しください。

技術的な注記

公開HTTP APIはバージョニングの示し方を場所ごとに変えます。api_version=2、あるいはクライアントに Accept や独自ヘッダーを送らせる前提で URL 上には何も置かない場合です。連携処理、ゲートウェイ、SDK 生成器、ドキュメント用クローラは、あるエンドポイント URL がどの方式を使い、どのバージョン・トークンを持つかについて、決定的で一意の答えを必要とします。本機能は絶対形式の API URL を1つ受け取り、http または https として整形式でない文字列を拒否し、方式を path_based、query_param、header_implied のいずれかに分類します。どちらにも慣例的なバージョン印がない場合は has_version が false の header_implied となり、URL に対して帯外でバージョンが伝わることを示します。

パス・クエリ・ヘッダー暗黙の方式をどう見分けるか

v1、v2、v1.2.3 のような区切りが pathname に現れ、しばしば /api/ 配下やホスト直後の意味ある最初の区切りになります。version/1 や versions/2.0 の二区切り形も認識し、ドキュメント風ルートも正しく分類します。キーは大文字小文字を無視して照合し、固定優先度リストで空でない値を持つ最初のキーが勝つため、元 URL のパラメータ順に依存せず結果が安定します。値は 2、v2、1.0.0 などがあり、トークンが任意のドット付き純数値なら先頭の v を正規化後の version から取り除きます。beta や 2024-01-01 のような自由形式の英数字トークンは、安全な識別子パターンに合う場合はそのまま残します。検出器はネットワーク入出力を行わず、ホスト名だけからバージョンを捏造しません。パス型バージョニングは REST の主流です。本検出器はパス区切りを左から右へ走査し、大文字小文字を区別せず v の直後に数値バージョンがある一致を path_based とみなし、数値部を version、元の区切りを version_raw、location をその区切り（例: /v2）に設定して返します。クエリ・パラメータ型は検索文字列に version、api_version、api-version、apiversion、ver、v などの一般的なキーでトークンを置きます。パスとクエリの両方が一致しうる場合は path_based を優先します。公開 REST ドキュメントではパス区切りを主契約、クエリを二次上書きとみなすのが一般的だからです。どちらからもバージョンが得られない場合、scheme は header_implied です。URL だけではバージョンを符号化せず、現代の API では Accept: application/vnd.example.v1+json、独自の X-API-Version ヘッダー、または未バージョン面を意味することが多いです。

入力契約・成功ペイロード・検証エラー

値は http または https スキームの整形式な絶対 URL でなければなりません。例: https://api.example.com/users?必須の文字列フィールド url を1つ持つ JSON 本文を POST してください。相対パス、スキームなしのホスト名、空文字、非文字列型、ftp や mailto などの他プロトコルは invalid_input で失敗し課金されません。成功時、応答には常にエコーされた url、scheme（path_based、query_param、header_implied のいずれか）、has_version（真偽値）、path（pathname）、host が含まれます。has_version が true のときは version（正規化トークン）、version_raw（URL 上の表記）、location（/v2 や ?api_version=2 のような短い指針）も含まれます。query_param 結果では param_name が URL 上のキーの元の綴りを記録します。has_version が false のとき任意フィールドは null にせず省略し、DOM 安全で描画しやすい契約を保ちます。例: https://api.example.com/v2/users は scheme path_based、version 2、location /v2 を返します。api_version=2 は scheme query_param、version 2、param_name api_version を返します。例: バージョン印のない https://api.example.com/users は scheme header_implied と has_version false を返します。単発の確認には無料ブラウザツールを、在庫ファイルや OpenAPI クロールから一括分類するときは成功1件あたり $0.002 の API をご利用ください。

URL バージョニング検出が役立つ場面

プラットフォームチームは社内・パートナーのベース URL を数百件単位で棚卸しし、非推奨ウィンドウを強制するゲートウェイへトラフィックを流す前に一貫したラベルを必要とします。検証失敗は残高を消費しません。SDK 生成器やクライアント足場ツールは、サーバがパスに /vN/ を期待するか、クエリ旗か、ヘッダーのみのバージョニングかをテンプレート分岐に使い、純粋な分類器があればリポジトリに散在する脆い正規表現を避けられます。ドキュメントサイトや API マーケットプレイスは各掲載の横にバージョニング様式のバッジを出し、本エンドポイントを供給すればマーケティング文面と実 URL の形が揃います。セキュリティやコンプライアンスのレビューでは、本番ホストがいまだ未バージョンのパスや混在スキームを露出していないかを問うことが多く、scheme と has_version を表へ書き出せば一回で答えられます。CI ジョブは、新規サービスのベース URL が ADR なしに path_based から header_implied へ静かに切り替わったときプルリクエストを失敗させられます。実装は tier A の純粋 parse のため、成功呼び出しは公開された基本料金 $0.002 で、モデル・トークンも対象ホストへの外向き取得もありません。

連携の活用例

API 在庫とゲートウェイ経路制御

サービスカタログのベース URL を path_based、query_param、header_implied に分類してから、非推奨ポリシーと経路規則を適用します。

SDK・クライアントの足場

SDK 生成時に正しい URL テンプレートを選びます。/vN/ の挿入、?version= の付与、URL にバージョンがない場合の必須 Accept ヘッダーの文書化です。

ドキュメント用バッジとコンプライアンス監査

公開 API 一覧にバージョニング様式を付与し、セキュリティやアーキテクチャレビューで未バージョンの本番ホストを示します。

技術的な質問

URL から API のバージョニング方式をどう検出しますか？

url フィールドに整形式の絶対 http(s) URL を送ってください。応答の scheme は path_based、query_param、header_implied のいずれかで、パスまたはクエリに版がある場合は version が抽出されます。

どのクエリ・パラメータが認識されますか？

version、api_version、api-version、apiversion、ver、v です。大文字小文字を無視し、この優先順で最初の空でない値が scheme query_param になります。

header_implied とは何を意味しますか？

パスにもクエリ文字列にも慣例的なバージョン印がありません。バージョニングはヘッダー（Accept、X-API-Version）で伝わるか、URL 上は未バージョンの API です。

API バージョニング方式の検出はいくらかかりますか？

ブラウザツールは無料です。API 要求は前払い KIT 残高から成功1回あたり $0.002 です。無効または非整形式の URL は課金されません。

KITの完全なドキュメントを見る →