REST API設計ガイド

dev/rest-api-design

RESTful API設計のベストプラクティスと命名規則を一覧表示する。

最終更新日 2026-07-03 ・ by yuzlrin

このツールでできること

REST API設計ガイドでは、RESTful API設計のベストプラクティスと命名規則を一覧表示する。
関連する観点として REST API、API設計、RESTful を確認し、結果をコピーして別の作業に使えます。

結果

--- URL設計 ---
GET    /users          ユーザー一覧
GET    /users/:id      ユーザー詳細
POST   /users          ユーザー作成
PUT    /users/:id      ユーザー更新(全体)
PATCH  /users/:id      ユーザー更新(部分)
DELETE /users/:id      ユーザー削除

--- 命名規則 ---
✅ /users (複数形)
❌ /user, /getUsers
✅ /users/123/posts (ネスト)
❌ /getUserPosts
✅ ケバブケース: /user-profiles
❌ キャメルケース: /userProfiles

--- クエリパラメータ ---
?page=1&per_page=20      ページネーション
?sort=created_at&order=desc  ソート
?filter[status]=active   フィルタ
?fields=id,name,email    フィールド選択
?q=keyword               検索

--- レスポンスコード ---
200 成功
201 作成成功
204 削除成功(ボディなし)
400 リクエスト不正
401 認証エラー
403 権限なし
404 リソースなし
409 競合
422 バリデーションエラー
429 レート制限
500 サーバーエラー

使い方

結果欄のURL設計セクションで、GET、POST、PUT、PATCH、DELETEと /users の対応を確認します。
命名規則セクションで、複数形、ネスト、ケバブケースの例と避ける例を見比べます。
クエリパラメータの例から、ページネーション、ソート、フィルタ、フィールド選択、検索の名前を確認します。
レスポンスコード一覧を見て、成功、認証、権限、競合、バリデーション、レート制限をAPI仕様書に反映します。

入力例・出力例

INPUT

URL設計

OUTPUT

GET /users ユーザー一覧 GET /users/:id ユーザー詳細 POST /users ユーザー作成

固定テキスト先頭の代表行です。

INPUT

クエリパラメータ

OUTPUT

?page=1&per_page=20 ページネーション ?sort=created_at&order=desc ソート

ページングとソートの例をそのまま確認できます。

INPUT

レスポンスコード

OUTPUT

409 競合 422 バリデーションエラー 429 レート制限

競合、検証失敗、レート制限の行が含まれます。

よくある利用シーン

新しいCRUD APIを作る前に、URL、HTTPメソッド、ステータスコードの基準を短く揃えたいとき。
レビューで /getUsers や単数形URLを見つけ、リソース指向の表現へ直す根拠を共有したいとき。
検索、フィルタ、フィールド選択などクエリ名の慣習を仕様書へ書き写したいとき。
OpenAPIを詳しく書く前の初期メモとして、REST設計の型をチームで確認したいとき。

結果確認のポイント

構文、引用符、改行、エスケープが利用先の仕様に合っているか確認してください。
REST API、API設計、RESTfulの観点で、入力内容と出力内容がずれていないか見直してください。
コピーした結果を利用先に貼り付けたあと、改行や記号が変わっていないかも確認してください。

注意点

本番の秘密情報、APIキー、パスワードは入力しないでください。
結果を公開・送信する前に、用途に合う形式かを必ず確認してください。

データの扱い / プライバシー

REST API設計ガイドの主要な処理はブラウザ内で実行されます。
入力内容を保存するアカウント機能はなく、ページを閉じると作業内容は手元のブラウザから離れます。
本番の秘密情報や個人情報を扱う場合は、入力前に必要性を確認してください。

FAQ

よくある質問

HTTPメソッドの使い分けはどう決めますか？

GETはリソース取得（冪等・安全）、POSTは新規作成（非冪等）、PUTはリソース全体の置き換え（冪等）、PATCHは部分更新（非冪等）、DELETEは削除（冪等）に使います。冪等とは同じリクエストを複数回送っても結果が変わらない性質で、設計判断の基準になります。

ステータスコードの使い分けで迷ったらどうしますか？

成功は200番台（200 OK、201 Created、204 No Content）、クライアント起因のエラーは400番台（400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found）、サーバー起因のエラーは500番台（500 Internal Server Error）を使うのが基本です。

リソースURLの命名はどのようにすべきですか？

URLにはリソースを表す名詞（複数形）を使います。例えば /users、/orders/{id} のように階層を表現し、動詞はHTTPメソッドに委ねます。バージョンは /v1/users のようにパスに含めるのが一般的です。

REST API設計ガイド

このツールでできること

使い方

入力例・出力例

よくある利用シーン

結果確認のポイント

注意点

データの扱い / プライバシー

よくある質問

関連ツール

REST API設計ガイド

このツールでできること

使い方

入力例・出力例

よくある利用シーン

結果確認のポイント

注意点

データの扱い / プライバシー

よくある質問

関連ツール