メインコンテンツへスキップ

REST APIの基本

🔗 REST APIとは

REST APIとは、HTTPをベースにした「リソース指向」のAPI設計スタイルです。
Webサービス同士が、URLとHTTPメソッドを使ってシンプルに情報をやり取りするための設計原則として広く使われています。

🧪 RESTとは？

RESTは「REpresentational State Transfer」の略。
2000年にロイ・フィールディングが博士論文で提唱したアーキテクチャスタイルで、Webの設計原則を抽象化したものです。

RESTは「ルール」ではなく「思想」に近く、HTTPの設計をより自然で拡張しやすい形にするためのガイドラインです。

🧱 RESTの6つの原則（ざっくり）

原則 意味と概要
クライアント-サーバ UI（クライアント）と処理（サーバ）を分離
ステートレス 各リクエストは独立して完結。サーバ側は状態を保持しない
キャッシュ可能 レスポンスはキャッシュ可能と不可の指定ができる
統一インターフェース 一貫したURL構造とメソッドの使い方（後述）
階層構造 リソースはURLの階層で表現され、透過的なプロキシなども使える設計
コードオンデマンド（任意） JavaScriptなどを動的にクライアントに送ることで、機能を拡張可能にする

🌳 リソースとURL設計（RESTらしさの核心）

RESTでは「リソース（=名詞）」をURLで表します。

  • 商品 → /products

  • ユーザー → /users

  • 注文 → /orders

そのリソースに対して、HTTPメソッド（動詞）を使って操作します。

HTTPメソッド 操作 対象 例
GET 取得 一覧 or 個別 /products, /products/123
POST 作成 一覧（に新規追加） /products
PUT 上書き 個別リソース /products/123
PATCH 一部更新 個別リソース /products/123
DELETE 削除 個別リソース /products/123

URLの中に動詞を入れないのがRESTのスタイルです（× /getProduct、◯ /products/123）。

🛠️ REST APIの実装イメージ

1. 商品の一覧を取得

GET /products
→ 200 OK
[
  {"id": 1, "name": "みかん"},
  {"id": 2, "name": "りんご"}
]

2. 商品を追加

POST /products
Content-Type: application/json

{
  "name": "バナナ"
}
→ 201 Created

3. 商品の削除

DELETE /products/2
→ 204 No Content

🧭 REST API設計のベストプラクティス

項目 推奨される設計
URL構造 名詞ベース（リソース）を使う
状態コード 適切なHTTPステータスを返す（200, 201, 204など）
エラーメッセージ JSONで返し、message, code, detailsなど含める
バージョン管理 URLやヘッダーで指定（例：/v1/products）
認証 BearerトークンやOAuthで実装する

URLに「動詞+名詞」が混ざっていると、RESTの設計原則から外れてメンテナンス性が落ちます。
（× /getAllProducts → ◯ /products + GET）

🔐 REST APIとセキュリティ

  • 認証：OAuth 2.0やAPIキーによるアクセス制限

  • 通信：HTTPSを必須化し、盗聴を防止

  • レート制限：APIの利用制限（DoS対策）を実装

🧾 OpenAPI（旧Swagger）での定義

OpenAPIを使うと、APIの仕様書をJSON/YAMLで記述し、
ドキュメントやモックサーバを自動生成できます。

例：Swagger UI で /products や /users にアクセスするためのGUIができる。

REST APIは多くのWebサービスやスマホアプリの裏側を支える標準インターフェースです。
API全体の概念については「APIの基本」もぜひ参考にしてください。


上に戻る