REST (ful) APIについて HTTPメソッド ステータスコード パラメータ クエリパラメータ パスパラメータ 使い分けの基準 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=electronicsとprice=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月から非推奨となりました。
HTTPヘッダーに独自の定義を追加する場合はX接頭辞が推奨されていましたが、2012年6月から非推奨となりました。
参考: