ForHosting KIT · サイト取得・監視

RESTエンドポイント命名チェック

/users/{id}/orders のようなパスを貼り付けると、小文字、ハイフン区切り、複数形の名詞、動詞なしという命名規則のどれを満たすかが分かります。違反はセグメントごとに示されるので、レビューの指摘がそのまま修正につながります。ブラウザで無料で使えます。

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

無料で実行 API仕様を見る

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

計算例

入力した場合

パス: /v1/users/{id}/orders

結果

セグメント: 4

パスを1つ送信すると、どの規則を満たし、どれに違反したか、問題のある各セグメントへの分かりやすい指摘を含む構造化された判定結果が返ります。レビューコメントが議論ではなく修正につながる結果です。

分かりやすいパス名の条件

広く受け入れられている規則は、各パスセグメントが名詞であること、そしてコレクションには複数形を使うことです。コレクションは /users、その1件は /users/{id} とします。セグメント内の単語はハイフンで区切る kebab-case スタイルを使います。

アンダースコアは URL で読みにくく、リンクの下線に隠れてしまうことがあり、camelCase は小文字が標準の場所に大文字小文字を持ち込んでしまうからです。v1 や v2 のようなバージョンプレフィックスは認められた慣行であり、命名エラーとしては扱われません。パスがこれらの規則に従うと予測可能になります。

このチェッカーの検査内容と判定方法

チェッカーはパスをスラッシュで分割し、クエリ文字列とフラグメントはリソースの命名に含まれないため無視します。残った各セグメントは4つのルールに照らして検査され、どの規則に違反しているかが正確に分かるよう、各ルールの失敗は個別に報告されます。

第一に小文字です。大文字を含むセグメントは、大文字小文字を区別するサーバーでのルーティングバグの原因になりやすいため指摘されます。第二にハイフン区切りです。セグメント内のアンダースコアや空白が指摘され、ハイフンが置き換え先として示されます。

第三に複数形の名詞です。バージョンプレフィックスでもパスパラメータでもないセグメントは、複数形らしい単語で終わることが期待されます。/user は指摘されますが /users は合格し、/user-profiles のような複合セグメントは最後の単語で判定されます。

第四に動詞です。ハイフンで区切られた各単語が、get、create、update、delete、fetch、login などの一般的な英語の動詞の固定リストと照合され、一致すれば指摘されます。{id} や :id という形式のパスパラメータは、静的なリソース名とは異なる規則に従うため、名詞と動詞のルールの対象外です。

活用例

設計レビューでのスタイル論争を決着させる

2人のレビュアーがパスの書き方で意見が分かれたとき、主観ではなく具体的な違反リストで判断します。

よくある質問

単語が複数形かどうかはどう判定するのですか？

単純で決定論的なヒューリスティックを使います。セグメントのハイフン区切りの最後の単語が 's' で終わる必要があります。v1 のようなバージョンセグメントや、{id} や :id のようなパスパラメータは対象外です。

クエリ文字列やフラグメントもチェックしますか？

いいえ。'?' や '#' 以降はチェックの前に除去されます。クエリパラメータとフラグメントはリソースの命名の一部ではないからです。

なぜアンダースコアではなくハイフンなのですか？

アンダースコアはWebアドレスの中で読みにくく、リンクの下線に隠れることがあります。camelCaseは小文字が基本の場所に大文字を混ぜてしまいます。そのため、アンダースコアと空白は指摘され、代わりにハイフンが示されます。

v1 のようなバージョン表記は指摘されますか？

いいえ。v1 や v2 のようなバージョンの接頭辞は広く使われている慣習なので、命名の誤りとしては扱われず、複数形の名詞である必要もありません。

{id} のようなパラメーターはどう扱われますか？

{id} や :id の形のパスパラメーターは、名詞と動詞の規則の対象外です。パラメーター名は固定のリソース名とは別の慣習に従うため、パスの評価を下げることはありません。

開発者向け — APIアクセス

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

エンドポイント

POSThttps://api.kit.forhosting.com/dev/rest-endpoint-naming-check

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

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

curl -X POST https://api.kit.forhosting.com/dev/rest-endpoint-naming-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"path":"/api/v1/user-profiles"}'

const res = await fetch("https://api.kit.forhosting.com/dev/rest-endpoint-naming-check", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "path": "/api/v1/user-profiles"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/rest-endpoint-naming-check",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "path": "/api/v1/user-profiles"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/rest-endpoint-naming-check", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"path":"/api/v1/user-profiles"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"path":"/api/v1/user-profiles"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/rest-endpoint-naming-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

リクエスト例

{
  "path": "/api/v1/user-profiles"
}

レスポンス例

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

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

料金

1リクエストあたり$0.002

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

制限

max_chars 2048

エラー

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

技術的な注記

REST エンドポイント命名チェッカーは、/users/{id}/orders のようなエンドポイントのパスを受け取り、主要なスタイルガイドが共通して推奨する規則に照らして各セグメントを検証します。セグメントは小文字であること、単語の区切りはアンダースコアや camelCase ではなくハイフンであること、コレクションのリソースは複数形の名詞であること、そして動詞はパスに含めないこと（HTTP メソッドがすでに操作を表しているため）という規則です。

良い REST パスとはどのようなものか

REST のパスは操作ではなくリソースを名指すものです。操作はすでに HTTP メソッド（GET、POST、PUT、DELETE）に含まれているため、/getUsers のようなパスは同じことを二度述べており、しかも API の他の部分と一貫しない言い方をしています。1つのエンドポイントを知っていれば、ドキュメントを読まずに残りの API も推測でき、ルーターやゲートウェイ、リンターなどのツールも一度設定すれば、チームが提供するすべてのサービスで再利用できます。

レビューとパイプラインで判定結果を活用する

出力は人が読みやすいだけでなく、機械処理にも適した設計です。典型的なワークフローは、サービスが追加する新しいルートすべてにチェッカーを実行することです。設計レビューの段階でパスを貼り付け、ルートがリリースされる前に逸脱を検出し、後になって「見た目の悪いパスを抱え続けるか、クライアントを壊す改名をするか」という苦しい選択を回避します。平易な言葉の指摘リストに加えて、lowercase、hyphenated、plural_nouns、no_verbs という規則ごとの真偽値を持つ checks オブジェクトと、全体の valid フラグが返ります。これにより、CI のジョブは文章を解析するのではなく、1つの条件でプルリクエストを失敗させられます。チームは API 監査でもこれを使い、OpenAPI ドキュメントのルートを入力して対処が必要なセグメントを集めます。API を支えるのと同じコードがこのページのブラウザ上で無料で動くため、設計中に対話的にパスを試すことができ、パイプラインやリンター、社内開発者ポータルでチェックを自動化する場合にだけ、リクエストごとに $0.002 を支払えばよいのです。

連携の活用例

CI で新しいルートをゲートする

新たに追加されたエンドポイントがパスに動詞、アンダースコア、大文字を持ち込んだ場合に、プルリクエストを失敗させます。

既存の API サーフェスを監査する

OpenAPI ドキュメントのルートをチェッカーに通し、スタイルガイドに違反しているセグメントを集めます。

技術的な質問

料金はいくらですか？

API 経由ではチェックしたパス1件につき $0.002 です。また、このページのブラウザ上では無料で実行できます。

なぜ REST パスに動詞を入れてはいけないのですか？

HTTP メソッドがすでに操作を表しているからです。/getUsers のようなパスは GET と重複し、API の他の部分と不整合になります。/users に GET メソッドを組み合わせれば、同じことが一貫して表現できます。

空のパスを送信するとどうなりますか？

空でないパスが必要であることを説明する invalid_input エラーでリクエストが失敗します。空の入力に課金されることはありません。

どの動詞リストを使っていますか？

実際の API で見られる一般的な英語の動詞（get、create、update、delete、fetch、find、search、add、remove、login、register など）の固定リストです。このリストは決定論的であり、呼び出しごとに変わることはありません。

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