Laravelで学ぶRESTful API:create・store・edit・updateの正しい使い分け
はじめに
システム部の李です。
今回は、Laravelでルートを設計する際によく使われる「RESTful API」について、弊社が運営している課金通話プラットフォーム「Port」の本人確認機能を例に、ルート設計やコントローラの使い分けとあわせてご紹介いたします。
RESTful APIとは:リソース指向とHTTPメソッド
技術的な観点から言うと、REST(REpresentational State Transfer)は、Webアーキテクチャの設計スタイルのひとつです。
その基本的な考え方は、「サーバー上の操作対象を情報(リソース)として捉え、一意のURI(統一資源識別子)でアクセスし、HTTPメソッド(GET、POST、PUT、DELETEなど)を使って操作する」というものです。
「RESTful」とは、「RESTの原則に従っている」「RESTらしい」という意味であり、RESTful APIとは、これらの設計ルールに沿って作られたAPIを指します。
生活に身近なたとえで言うと、ネットショップの商品を管理するシステムを想像してください。
「商品番号(URI)を指定して、その商品(リソース)をさまざまな方法(HTTPメソッド)で操作する」というイメージです。
- GET /products
→ 商品一覧を取得する
- POST /products
→ 新しい商品を登録する
- GET /products/1
→ IDが1の商品を表示する
- PUT /products/1
→ 商品の情報を更新する
- PATCH /products/1
→ 商品情報の一部だけを更新する(例:価格だけ変更など)
- DELETE /products/1
→ 商品を削除する
このように、RESTでは「どのリソースに、どの操作をするか」をHTTPメソッドで明確に表現します。
その考え方に基づいて設計されたのが、RESTful APIです。
LaravelにおけるCRUDルート:resourceコントローラの構造と使い方
Laravelでは、RESTfulなルーティングを簡潔に実現するために、リソースコントローラという仕組みが用意されています。
これは、CRUD(Create、Read、Update、Delete )操作に対応する7つのアクションを、1行のルート定義で自動的にマッピングできる便利な仕組みです。
1. ルート定義
Route::resource('products', ProductController::class);
ルートファイルにこの1行を追加するだけで、以下のようなHTTPメソッドとURIの組み合わせが自動で登録されます:
HTTPメソッド | URI | コントローラメソッド | 用途 |
GET | /products | index | 商品一覧を表示 |
GET | /products/create | create | 新規作成フォームを表示 |
POST | /products | store | 新しい商品を保存 |
GET | /products/{id} | show | 商品詳細を表示 |
GET | /products/{id}/edit | edit | 編集フォームを表示 |
PUT/PATCH | /products/{id} | update | 商品情報を更新 |
DELETE | /products/{id} | destroy | 商品を削除 |
2. コントローラ作成
php artisan make:controller ProductController --resource
続いて、以上のコマンドを実行すると、上記のルートに対応した7つのメソッドがあらかじめ定義されたコントローラが生成されます。
class ProductController extends Controller { public function index() { /* 商品一覧を表示する / } public function create() { / 商品の新規登録フォームを表示する / } public function store(Request $request) { / フォーム入力内容をもとに商品を登録する / } public function show($id) { / 指定された商品の詳細情報を表示する / } public function edit($id) { / 商品の編集フォームを表示する / } public function update(Request $request, $id) { / 編集フォームの入力内容をもとに商品情報を更新する / } public function destroy($id) { / 指定された商品を削除する */ } }
このように、1つのリソース(商品)に対する操作を、HTTPメソッドとURIの組み合わせで整理する点が、RESTの考え方と一致しています。
Laravelのリソースルートは、RESTfulなAPI設計を直感的かつ効率的に実現するためのベストプラクティスと言えるでしょう。
実例:本人確認機能の「作成」「編集」処理を正しく設計する
弊社が運営する課金通話プラットフォーム「Port」には、出店者向け機能の一つとして本人認証機能があります。
ここでは、本人確認機能における「作成」と「編集」処理を、RESTfulの考え方に沿ってどのように設計したかをご紹介します。
状態によるメソッドの使い分け
本人確認フローにおいて、リソースである「本人確認申請」に対して最低限必要な状態は次の5つです:
- 初回申請の登録
- 入力途中で中断した場合の再開
- 提出前の確認と、必要に応じた修正
- 提出済みで結果を待つ状態
- 却下後の再申請
それぞれの状態における操作と、使用するHTTPメソッドは以下の通りです:
状態 | 操作 | 使用メソッド |
新規申請 | 登録 | create / store |
入力途中(保存済み・未提出) | 続きから入力 | edit / update |
提出前の確認画面からの修正 | 内容の再編集 | edit / update |
提出済み | 編集・再申請不可 | —(操作なし) |
再申請(却下後) | 新たに申請 | create / store |
なお、このフローでは一覧表示や詳細表示、削除といった操作は不要なため、index、show、destroy メソッドは使用しません。
ルーティング設計
「作成」と「編集」のシナリオが明確になれば、それに応じたルート設計も決まります。
作成:create / store
- GET /identity-verification/create
→ 新規申請フォームを表示(create)
- POST /identity-verification
→ 入力内容をもとに申請を保存(store)
初回申請や、却下された申請の再提出は、いずれも新規レコードとして store を使用します。
編集:edit / update
- GET /identity-verification/{id}/edit
→ 入力途中または未提出の申請を編集フォームとして表示(edit)
- PUT /identity-verification/{id}
→ 内容を修正して再保存(update)
申請が「未提出」の場合、ユーザーは入力を途中で離れても後から再開できます。また、提出前の確認画面から戻って修正を行う場合も、edit / update を使用します。
このように、申請の状態に応じて create/store と edit/update を明確に使い分けることで、RESTの設計思想と実務要件の両立が可能になります。
まとめ
最後までお読みいただき、ありがとうございます!この文章を通じて、RESTful APIについての理解を少しでも深めていただけたなら幸いです。
弊社ではWeb開発案件も承っております。ご興味がございましたら、ぜひお問い合わせフォームよりお気軽にご相談ください。
参考資料
- Controllers: https://laravel.com/docs/12.x/controllers
- What Is a REST API? Examples, Uses, and Challenges: https://blog.postman.com/rest-api-examples/
- What is a RESTful API?: https://aws.amazon.com/what-is/restful-api/
- ChatGPT: https://chatgpt.com/