API設計

REST れすと

RESTful APIHTTPステートレスリソースWeb APIJSON

RESTについて教えて

簡単に言うとこんな感じ！

RESTはWeb APIを作るときの「お作法・設計ルール集」だよ。「この情報を取りたいならこのURLにGETしてね」「削除したいならDELETEでね」って、HTTPのしくみをうまく使って、誰でもわかりやすくAPIを設計しようという考え方なんだ！

RESTとは

REST（Representational State Transfer） は、2000年にRoy Fieldingが博士論文で提唱したWeb APIの設計スタイルです。特定のプロトコルや仕様ではなく、「こう設計すると使いやすくなるよ」というアーキテクチャ原則（設計思想）の集まりです。

RESTの最大の特徴は、Webがもともと持っているHTTPの仕組みを最大限に活かすという発想です。URLでリソース（情報の塊）を表し、HTTPメソッド（GET・POST・PUT・DELETEなど）で操作の種類を表現します。たとえば「注文番号123の情報を取得する」なら GET /orders/123 と表現します。これにより、URLを見るだけで何をしているかが直感的にわかります。

RESTの原則に従って設計されたAPIを RESTful API と呼びます。現在、スマホアプリ・Webサービス・クラウドサービスなど、ほぼあらゆるシステム連携でRESTful APIが使われており、現代のシステム間連携の事実上の標準となっています。

RESTの6つの設計原則

RESTには守るべき6つの制約（原則）があります。これを満たすほど「RESTらしい」設計になります。

原則	概要	たとえるなら
クライアント／サーバー分離	画面側（クライアント）とデータ側（サーバー）を分けて開発する	フロントとバックを別チームで作れる
ステートレス	各リクエストは完全に独立。サーバーは「前のやりとり」を覚えない	毎回自己紹介してからお願いする
キャッシュ可能	レスポンスをキャッシュ（一時保存）して再利用できるようにする	一度調べた答えはメモしておく
統一インターフェース	URL・HTTPメソッドのルールを統一して誰でも使いやすくする	共通の受付窓口・手続き様式
階層化システム	ロードバランサーやプロキシなどを挟んでも動く構造にする	受付→担当者→奥のシステムと透過的に通る
コードオンデマンド（任意）	必要に応じてサーバーからコードを送り実行できる（省略可）	レシピ（コード）ごとダウンロード

HTTPメソッドとCRUDの対応（覚え方）

「CRUD（クラッド）」 はデータ操作の4基本動作（Create・Read・Update・Delete）で、RESTではHTTPメソッドと対応させます。

HTTPメソッド	CRUD操作	意味	例
GET	Read（読む）	リソースを取得する	`GET /users/1` → ユーザー1の情報を取得
POST	Create（作る）	新しいリソースを作成する	`POST /users` → 新規ユーザーを登録
PUT	Update（更新する）	リソースを丸ごと上書き更新	`PUT /users/1` → ユーザー1を全項目更新
PATCH	Update（部分更新）	リソースの一部だけを更新	`PATCH /users/1` → 名前だけ変更
DELETE	Delete（消す）	リソースを削除する	`DELETE /users/1` → ユーザー1を削除

💡 覚え方： 「GETしてPOSTして、PUTしてDELETE。ゲット・ポスト・プット・デリート」と声に出して覚えよう！

URLの設計ルール（RESTらしいURL）

# ✅ RESTらしいURL（名詞・リソース中心）
GET    /products          # 商品一覧を取得
GET    /products/42       # 商品ID=42の詳細を取得
POST   /products          # 新しい商品を登録
PUT    /products/42       # 商品ID=42を更新
DELETE /products/42       # 商品ID=42を削除

# ❌ RESTらしくないURL（動詞が混ざっている）
GET    /getProduct?id=42
POST   /deleteProduct/42
GET    /products/getList

歴史と背景

1991年 — Tim Berners-LeeがWorld Wide Web（HTTP + URL + HTML）を発明。Webの基盤が生まれる
1994〜1999年 — Webが爆発的に普及。しかしシステム間連携には SOAP（XML形式の重厚な規格） が主流で、実装が複雑だった
2000年 — Roy Fielding（HTTP/1.1仕様策定者の一人）が博士論文「Architectural Styles and the Design of Network-based Software Architectures」でRESTを提唱
2004〜2006年頃 — Amazon・Google・FlickrなどがRESTful APIを公開し始め、開発者コミュニティで急速に普及
2010年代 — スマートフォンの普及でモバイルアプリとサーバー間の通信にRESTful APIが必須に。SOAPに代わりRESTが主流へ
2015年以降 — GraphQL・gRPCなどの新しいAPI設計手法も登場。RESTは引き続き最も広く使われる標準として君臨

REST vs 他のAPI設計スタイル

RESTは万能ではありません。用途によって向き・不向きがあります。

比較項目	REST	SOAP	GraphQL	gRPC
通信形式	HTTP + JSON/XML	HTTP + XML	HTTP + JSON	HTTP/2 + Protocol Buffers
取得データ	エンドポイント固定	エンドポイント固定	必要な項目だけ指定可	メソッド定義に従う
学習コスト	低い	高い	中程度	中程度
パフォーマンス	普通	低め	普通〜高め	高い
主な用途	汎用Web API	企業間連携・金融	複雑なデータ取得	マイクロサービス間通信
普及度	★★★★★	★★★	★★★★	★★★

規格・RFC番号	内容
RFC 7230	HTTP/1.1 メッセージの構文と転送（HTTPの基盤）
RFC 7231	HTTP/1.1 セマンティクスとコンテンツ（GETやPOSTなどのメソッド定義）
RFC 7232	HTTP/1.1 条件付きリクエスト（キャッシュ制御）
RFC 7234	HTTP/1.1 キャッシュ（RESTのキャッシュ可能原則に関わる）
RFC 9110	HTTP Semantics（HTTP全体の最新統合仕様、2022年）
RFC 6570	URI Template（RESTful APIのURL設計で利用される）