「TwitterのツイートをWebサイトに表示したい」 「Googleマップをアプリに組み込みたい」 「天気予報のデータを自動で取得したい」
こんなことを実現できるのが、REST（レスト）という仕組みです。
RESTは「Representational State Transfer」の略ですが、この難しい名前は忘れてOK。 簡単に言うと、「Webサービス同士が会話するための共通ルール」のことなんです。
レストランで注文するときのように、決まった方法でお願いすれば、欲しいものが返ってくる。 そんなシンプルな仕組みが、実は世界中のWebサービスをつないでいるんです。
この記事では、身近な例を使いながら、RESTの仕組みを分かりやすく解説していきます。 プログラミングを知らなくても大丈夫。一緒に、Webサービスの裏側を覗いてみましょう！
RESTを理解する一番簡単な例
レストランでの注文に例えると
RESTの仕組みは、レストランでの注文とそっくりです。
レストランでの流れ：
- メニューを見る（情報を取得）
- 料理を注文する（新規作成）
- 注文内容を変更する（更新）
- 注文をキャンセルする（削除）
RESTでも同じ：
- データを見る（GET）
- データを作る（POST）
- データを更新する（PUT）
- データを削除する（DELETE）
お客さん（あなたのアプリ）がウェイター（API）に決まった方法でお願いすると、 キッチン（サーバー）から料理（データ）が運ばれてくる。これがRESTの基本イメージです。
実際のWebサービスでの例
Twitterを例に見てみましょう。
ツイートを見る（GET）
- 「最新のツイートを見せて」とお願い
- Twitterが最新ツイート一覧を返す
ツイートを投稿（POST）
- 「このツイートを投稿して」とお願い
- Twitterが新しいツイートを作成
ツイートを編集（PUT）
- 「このツイートを修正して」とお願い
- Twitterがツイートを更新
ツイートを削除（DELETE）
- 「このツイートを削除して」とお願い
- Twitterがツイートを削除
どのWebサービスも、この4つの基本動作で操作できるんです。
RESTって何？正式な説明
RESTの定義
REST（Representational State Transfer）は、Webサービスを設計するときの設計思想（アーキテクチャスタイル）です。
2000年にロイ・フィールディングという人が提唱しました。 彼はHTTP（Webページを見る仕組み）の開発にも関わった、Web界のレジェンドです。
RESTに従って作られたWebサービスを「RESTful（レストフル）」と呼びます。 「RESTっぽい」という意味ですね。
なぜRESTが必要？
RESTが生まれる前は、各社が独自のルールでWebサービスを作っていました。
問題点：
- A社のサービスとB社のサービスをつなぐのが大変
- 新しいサービスごとに使い方を覚える必要がある
- 複雑で理解しにくい
RESTという共通ルールができたことで：
- どのサービスも同じような使い方ができる
- 簡単にサービス同士を連携できる
- 学習コストが下がる
まるで、世界共通の交通ルールができたようなものです。
RESTの6つの原則
1. クライアント・サーバー分離
役割を明確に分けます。
- クライアント（利用者）：画面表示や操作を担当
- サーバー（提供者）：データの保存や処理を担当
レストランで言えば、客席とキッチンを分けるようなもの。 それぞれが自分の仕事に集中できます。
2. ステートレス（状態を持たない）
サーバーは前回のやり取りを覚えていません。
例：コンビニの店員
- 毎回「いらっしゃいませ」から始まる
- 前回何を買ったか覚えていない
- でも、そのおかげで誰でも平等にサービスを受けられる
毎回必要な情報をすべて送ることで、シンプルな仕組みを保っています。
3. キャッシュ可能
一度取得したデータは保存して再利用できます。
例：天気予報
- 1分前に取得した天気予報は、そのまま使える
- 毎回サーバーに聞く必要がない
- 通信量と時間を節約
4. 統一インターフェース
どのサービスも同じ方法で使えます。
例：自動販売機
- どのメーカーの自販機も基本操作は同じ
- お金を入れる→ボタンを押す→商品が出る
- 初めて見る自販機でも使い方が分かる
5. 階層型システム
複数のサーバーを経由してもOKです。
例：宅配便
- 送り主→集荷所→配送センター→配達先
- 途中に何段階あっても、荷物は届く
6. コードオンデマンド（オプション）
必要に応じてプログラムを送ることもできます。
例：JavaScriptを送って、ブラウザで実行 （この原則は必須ではありません）
HTTPメソッド（動詞）の使い方
4つの基本メソッド
RESTでは、やりたいことを「動詞」で表現します。
GET（取得）
- データを見るだけ
- 何も変更しない
- 何度実行しても安全
- 例：商品一覧を見る、ユーザー情報を取得
POST（作成）
- 新しいデータを作る
- 実行するたびに新しいものができる
- 例：新規会員登録、ブログ記事の投稿
PUT（更新）
- 既存のデータを丸ごと置き換える
- 何度実行しても結果は同じ
- 例：プロフィール更新、商品情報の編集
DELETE（削除）
- データを削除する
- 一度削除したら元に戻せない
- 例：アカウント削除、投稿の削除
実際のURL例
Instagramの写真を例にすると：
GET /photos → 写真一覧を取得
GET /photos/123 → ID:123の写真を取得
POST /photos → 新しい写真を投稿
PUT /photos/123 → ID:123の写真を更新
DELETE /photos/123 → ID:123の写真を削除
URLは「名詞」、メソッドは「動詞」という関係です。
データのやり取り（JSONとXML）
JSON（ジェイソン）形式
最も使われているデータ形式です。
JSONの例（ユーザー情報）：
{
"name": "田中太郎",
"age": 25,
"email": "tanaka@example.com",
"hobbies": ["読書", "映画", "料理"]
}
特徴：
- 人間にも読みやすい
- JavaScriptと相性が良い
- 軽量で高速
- 現在の主流
XML形式
以前はよく使われていた形式です。
XMLの例（同じユーザー情報）：
<user>
<name>田中太郎</name>
<age>25</age>
<email>tanaka@example.com</email>
<hobbies>
<hobby>読書</hobby>
<hobby>映画</hobby>
<hobby>料理</hobby>
</hobbies>
</user>
JSONの方がシンプルなので、今はJSONが主流です。
実際のREST APIの例
GitHub API
プログラマーがよく使うGitHubのAPI例：
GET /users/octocat
→ octocatさんの情報を取得
GET /users/octocat/repos
→ octocatさんのリポジトリ一覧
POST /user/repos
→ 新しいリポジトリを作成
天気予報API
天気情報を取得する例：
GET /weather?city=tokyo
→ 東京の天気を取得
GET /forecast/5day?city=osaka
→ 大阪の5日間予報を取得
YouTube API
動画情報を扱う例：
GET /videos?part=snippet&chart=mostPopular
→ 人気動画を取得
GET /search?q=猫&type=video
→ 「猫」で動画検索
RESTのメリット・デメリット
メリット
1. シンプルで分かりやすい
- HTTPの仕組みをそのまま使える
- 特別な知識がなくても理解しやすい
2. 拡張性が高い
- 新しい機能を追加しやすい
- 既存の機能に影響を与えにくい
3. 言語に依存しない
- どのプログラミング言語からでも使える
- Web標準技術だけで実現できる
4. キャッシュが使える
- 同じデータを何度も取得しなくて済む
- サーバーの負荷を減らせる
5. テストが簡単
- ブラウザやツールで簡単にテストできる
- 開発効率が上がる
デメリット
1. リアルタイム通信に不向き
- チャットなどには別の仕組み（WebSocket）が必要
2. 複雑な操作が苦手
- 複数のリソースをまとめて操作するのが面倒
3. 標準化されていない部分もある
- エラー処理などは各社バラバラ
4. 過剰な通信が発生することも
- 必要ない情報まで取得してしまうことがある
REST以外の選択肢
GraphQL（グラフQL）
Facebookが開発した新しい方式です。
特徴：
- 必要なデータだけを指定して取得できる
- 1回のリクエストで複数のデータを取得
- RESTより効率的な場合がある
SOAP（ソープ）
RESTより前からある方式です。
特徴：
- より厳密で安全
- 銀行などの重要なシステムで使用
- 複雑で学習コストが高い
gRPC（ジーアールピーシー）
Googleが開発した高速通信方式です。
特徴：
- バイナリ形式で高速
- マイクロサービス間の通信に適している
- Webブラウザからは直接使えない
RESTful APIの設計のコツ
良いURL設計
良い例：
/users/123/posts （ユーザー123の投稿一覧）
/products/search?category=books （本を検索）
悪い例：
/getUserPosts （動詞を使っている）
/products-list-all （冗長）
わかりやすいレスポンス
成功時：
{
"status": "success",
"data": { ... }
}
エラー時：
{
"status": "error",
"message": "ユーザーが見つかりません",
"code": 404
}
バージョン管理
APIを更新するときは、バージョンを付けます：
/v1/users （バージョン1）
/v2/users （バージョン2）
古いバージョンも残すことで、既存のアプリが壊れません。
よくある質問
Q：RESTとRESTfulの違いは？
A：RESTは設計思想、RESTfulはそれに従って作られたもの。 「RESTful API」は「RESTの原則に従ったAPI」という意味です。
完璧にRESTの原則を守るのは難しいので、「RESTっぽい = RESTful」と表現します。
Q：APIキーって何？
A：APIを使うための「パスワード」のようなものです。
例：Google Maps APIを使うとき
- APIキーを取得（無料）
- リクエストにキーを含める
- Googleがキーを確認して許可
これにより、誰が使っているか分かり、悪用を防げます。
Q：REST APIは無料？
A：サービスによります。
- 無料：多くのサービスが基本機能は無料
- 制限付き無料：1日1000回までなど
- 有料：大量利用や高度な機能
TwitterやGitHubは基本無料、Google Mapsは一定量まで無料です。
Q：プログラミングできなくても使える？
A：ツールを使えば可能です。
- Postman：GUIでAPIをテストできる
- Zapier：プログラミング不要でAPI連携
- IFTTT：簡単な自動化ツール
ただし、本格的に使うにはプログラミングの知識があった方が便利です。
まとめ
REST（Web REST）は、Webサービス同士が会話するための共通ルールです。
押さえておきたいポイント：
- GET（見る）、POST（作る）、PUT（更新）、DELETE（削除）の4つが基本
- URLは「名詞」、メソッドは「動詞」として設計
- JSONという形式でデータをやり取り
- HTTPの仕組みをそのまま活用
- シンプルで分かりやすいのが最大の特徴
RESTのおかげで、TwitterとInstagramを連携させたり、天気予報を自分のサイトに表示したり、様々なサービスを組み合わせることができるようになりました。
今や世界中のWebサービスがRESTでつながっています。 あなたが使っているアプリも、裏ではRESTを使って他のサービスと連携しているはずです。
プログラミングを学ぶなら、RESTは避けて通れない重要な概念。 でも基本はとてもシンプルなので、恐れる必要はありません。
まずは「レストランの注文」のイメージを覚えておけば、RESTの本質は理解できたも同然ですよ！
コメント