【Webアプリ開発2026 #18】REST(ful) API

REST (ful) APIについて

Webシステムを外部から利用するためのプログラムの呼び出し規約(API)の種類の一つで、REST原則に従って策定されたもの
引用:https://e-words.jp/w/REST_API.html

REST APIとは、前章で学んだREST原則に従って設計されたWeb APIのこと。HTTP技術をベースとしており、HTTPメソッド(GET、POST、PUT、PATCH、DELETE)を使ってクライアントとサーバー間でデータをやり取りする。

HTTPメソッド

HTTP(HyperText Transfer Protocol)は、WebサーバとクライアントのWebブラウザがデータを送受信するために使用するプロトコル。HTTPメソッドは、リクエストを行う際に「どのような操作を行いたいか」を表現する。

メソッド名 説明 具体例
GET リソースの取得 ユーザー一覧を取得する、商品の詳細を見る
POST リソースの新規登録 新しいユーザーを作成する、注文を確定する
PUT 既存リソースの全体更新 ユーザー情報を丸ごと置き換える
PATCH 既存リソースの部分更新 ユーザー名だけを変更する
DELETE リソースの削除 ユーザーを退会させる、商品を取り下げる

PUTとPATCHの違い

同じ「更新」でも、送るデータの範囲が異なる。

PUT /products/123
→ リソース全体を送る(送らなかったフィールドはnullや初期値になる)
{ "name": "Tシャツ", "price": 2000, "description": "コットン100%" }

PATCH /products/123
→ 変更したいフィールドだけ送る(送らなかったフィールドはそのまま)
{ "price": 1500 }
ℹ️
HTMLのformタグはGETとPOSTしか対応していないため、更新や削除もPOSTを利用しているケースがある。REST APIではこれらのメソッドを正しく使い分ける。

ステータスコード

HTTPステータスコードとは、サーバーがクライアントに返す3桁の数字。リクエストの結果(成功、エラー等)を表す。

ステータスコード 状態 説明 よく見るもの
100番台 情報 リクエストを受け付けて処理中 100 Continue
200番台 成功 リクエストが正常に処理された 200 OK、201 Created
300番台 リダイレクト 追加の処理が必要(別URLへ転送等) 301 Moved Permanently
400番台 クライアントエラー リクエスト側に問題がある 400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、422 Unprocessable Entity
500番台 サーバーエラー サーバー側で問題が発生 500 Internal Server Error

運用上のポイント

  • 適切なステータスコードを返す
    • 全て200で返すと、クライアント側でエラーハンドリングができない
  • 400番台と500番台の意味を理解する
    • 400番台はクライアントの問題(URLの打ち間違い、必須パラメータの不足等)
    • 500番台はサーバーの問題(バグ、DB接続障害等)
  • 500番台の監視体制を作る
    • 本番運用では500番台のエラーが出たらアラートを飛ばし、すぐに調査する

パラメータ

REST APIでは、リクエストに追加情報を渡す方法が複数ある。

クエリパラメータ

URLの ? の後に key=value 形式で付与する。検索条件やフィルタリングに使う。

https://example.com/products?category=electronics&price=1000
  • category=electronicsprice=1000 がクエリパラメータ
  • 複数ある場合は & で繋ぐ
  • 用途: 一覧取得時の絞り込み、ページネーション(?page=2&limit=20)など
パスパラメータ

URLのパス部分に埋め込む。特定のリソースを一意に指定するのに使う。

https://example.com/products/12345
  • 12345 がパスパラメータ(商品ID)
  • 用途: 特定のリソース1件を取得・更新・削除するとき
使い分けの基準
パラメータ種類 いつ使うか
パスパラメータ リソースを一意に特定するとき /users/123(ID=123のユーザー)
クエリパラメータ 検索・フィルタ・ページネーション /users?role=admin&page=2

APIのバージョン管理

APIは一度公開すると、利用者(クライアント)がそのインターフェースに依存する。大きく仕様を変えると既存のクライアントが動かなくなるため、バージョンを分けて管理する。

なぜバージョン管理が必要か

  • レスポンスの形式を変えたい(フィールド名の変更、構造の変更)
  • エンドポイントの設計を見直したい
  • 破壊的変更を入れたいが、既存の利用者を壊したくない

バージョンの表現方法

パターン サンプル 特徴
パスに含める https://api.example.com/v1/users/ 最も一般的。URLを見ればバージョンがわかる
クエリで指定 https://api.example.com/users?version=1 あまり使われない
ヘッダーで指定 GET /users/ + X-Api-Version: 1 URLがきれいに保てるが、ブラウザでの確認がしづらい

実務ではパスに含める方式が最も多い。

ℹ️
X接頭辞について
HTTPヘッダーに独自の定義を追加する場合はX接頭辞が推奨されていましたが、2012年6月から非推奨となりました。

参考: