RESTとは何か？意味と基本原則をゼロから理解する

Web APIの仕様書に「このサービスはREST APIです」と書かれていても、実際に何を守ればよいのか分からず設計レビューで指摘された経験がある方は多いはずです。
曖昧なまま言葉だけが一人歩きすると、チーム内で話がかみ合わなくなったり無駄な実装が増えたりします。
この記事では、RESTという言葉の正体を「意味」「背景」「基本原則」の順に整理しながら、日々の開発でどう考えればよいかを具体的に解説します。

RESTとは何かをやさしく整理する

まずはRESTという言葉そのものの意味と背景を整理します。
単なる「JSONを返すAPIの呼び名」ではなく、どんな思想と制約から成り立っているのかを押さえることで、表面的な「RESTっぽさ」に振り回されにくくなります。

結論：RESTの要点3つ

最初に、RESTをざっくり3つの要点にまとめると次のようになります。

1つ目は、RESTは「設計上の制約条件の集合」でありプロトコル名ではないという点です。
代表的にはクライアントサーバー、ステートレス、キャッシュ可能性、統一インターフェースなどの制約があります。(roy.gbiv.com)

2つ目は、RESTは「リソース」とその「表現」をやり取りするスタイルだということです。
URIで指し示されるリソースを、JSONやHTMLなどの表現にしてクライアントとサーバーでやり取りします。(MDNウェブドキュメント)

3つ目は、HTTPの設計思想と相性が良く、多くのREST風APIがHTTP上で実装されているという点です。
HTTPメソッドやステータスコードの意味を尊重することで、理解しやすく拡張しやすいAPIになります。(RFCエディタ)

現場では、これらの制約の全部を厳密に満たすケースばかりではありません。
しかし「どの制約をどこまで意識できているか」が、RESTを名乗るかどうかの現実的な判断基準になっています。

用語の意味と背景にある考え方

RESTは「Representational State Transfer」の略で、日本語では「表現状態の転送」と訳されます。
この用語は、Webのアーキテクチャを分析したRoy Fieldingの博士論文で提案されたアーキテクチャスタイルの名前です。(roy.gbiv.com)

ここでいう「状態（State）」は、クライアントが今どのリソースにアクセスしているかなど「アプリケーションの現在位置」のようなものです。
ブラウザでリンクをたどってページを移動していくとき、ページ遷移ごとに状態が変わりますが、その状態の変化を「表現（HTMLなど）」のやり取りとして転送している、というイメージです。

初心者がよく混同するのが「RESTという新しい通信方式がある」という誤解です。
RESTは通信方式そのものではなく、既存のプロトコル（代表的にはHTTP）をどう設計して使うかという指針に近いものだと考えると理解しやすくなります。

RESTとHTTP・APIの関係

実務では「REST API」「RESTful API」という言葉が、しばしば「HTTPでJSONを返すAPI」とほぼ同義で使われます。
しかし、本来の定義では「RESTの制約に従って設計されたアーキテクチャ」を指し、HTTPはその上でよく使われる基盤技術の一つという位置づけです。(MDNウェブドキュメント)

例えば、HTTPのGETメソッドは「リソースの取得」、POSTは「新規作成や処理のトリガー」といった意味が定義されています。(MDNウェブドキュメント)
REST風のAPI設計では、この意味をできるだけ尊重してURIやメソッドを決めていきます。

開発の現場では、次のような会話がよく起こります。

「とりあえず全部POSTにしておけばRESTですよね。」
「いや、それだとHTTPの意味を崩してしまうので、GETやPUTも使い分けたほうがよいです。」

このように、RESTという言葉をきっかけにHTTPの使い方を見直すケースは少なくありません。

RESTでいう「リソース」とは何か

RESTでは「リソース」という概念が非常に重要です。
リソースとは「名前をつけて識別できる情報のまとまり」であり、必ずしもデータベースのテーブル1つと一対一で対応するわけではありません。(roy.gbiv.com)

例えば、ECサイトなら次のように考えられます。

• /products … 商品の一覧というリソース
• /products/123 … IDが123の商品というリソース
• /users/456/orders … ユーザー456の注文履歴というリソース

ここで大事なのは、URIには「どう取得するか」ではなく「何を表すか」を反映させるということです。
/getProducts.phpのような名前は処理を表しており、RESTのリソース指向の考え方とは少し離れてしまいます。

現場では、画面単位やビジネス機能単位でURIを切りたくなりがちです。
しかし「それはどんなリソースを表しているのか」を一度言葉で説明してみると、URI設計の軸がぶれにくくなります。

判断基準：どこまで満たせばRESTと呼べるか

RESTは「制約条件の集合」なので、理屈だけでいえばすべての制約を満たしていないと厳密にはRESTとは呼べないという見方が一般的です。(roy.gbiv.com)
ただし実務では、そこまで厳しい線引きをしていないプロジェクトも多くあります。

現場でよく使われる現実的な判断基準としては、次のようなものがあります。

• URIがリソース指向で設計されているか
• HTTPメソッドの意味（GETは取得、POSTは新規作成など）を大きく外していないか
• セッションに過度に依存せず、リクエスト単位で完結するよう意識しているか

これらをある程度満たしていれば「REST風」「RESTベースのAPI」と表現し、すべての制約を細かく守っている場合に「RESTfulである」といったニュアンス分けをするケースもあります。

注意点・よくある誤解

RESTに関するよくある誤解と注意点をいくつか挙げます。

1つは、「JSONを返していればREST」ではないという誤解です。
レスポンス形式はRESTの一部でしかなく、リソース指向やステートレス性などの制約をどう扱っているかが重要です。

もう1つは、「RESTはHTTP専用の概念」だと決めつけてしまうことです。
実際にはRESTはアーキテクチャスタイルの名前であり、HTTP以外にも適用は可能です。
ただしWeb開発の世界ではHTTPとの組み合わせで語られることが圧倒的に多い、というのが実情です。(MDNウェブドキュメント)

さらに、「RESTに従うこと」自体が目的化してしまうケースにも注意が必要です。
ビジネス要件、既存システムとの整合性、チームのスキルなどによっては、RESTの一部制約を意図的に緩めたほうが現実的な場合もあります。
その際は、どの制約をどの理由で緩めているのかを言語化しておくと、後続メンバーにも伝わりやすくなります。

RESTの基本原則と実務での押さえどころ

次に、RESTの代表的な制約と、それを実務でどう意識すればよいかを見ていきます。
すべてを丸暗記する必要はありませんが、判断に迷ったときに立ち返る「ものさし」として覚えておくと、設計のブレを減らせます。

クライアントサーバーとステートレス性

RESTの前提として、クライアントとサーバーの責務を分離する「クライアントサーバー」モデルがあります。(roy.gbiv.com)
クライアントはUIやユーザー体験に集中し、サーバーはデータやビジネスロジックを担当する、という役割分担です。

ここで重要になるのがステートレス性です。
ステートレスとは「サーバー側がクライアントの状態をセッションとして持たず、各リクエストが独立して完結するようにする」考え方です。(roy.gbiv.com)

例えば、次のような実装はステートレス性を損ねやすい代表例です。

• ログイン後の状態をサーバーのメモリにだけ保持しており、どのサーバーに当たるかで動作が変わる
• 「前のリクエストで取得した一覧」を前提にして、次のリクエストの挙動が決まる

一方で、アクセストークンやクッキーを用いた認可情報そのものは、ステートレス性と両立させながら設計することが一般的です。
「サーバー側にだけ持ったら困る情報ではないか」「別のサーバーにリクエストしても解釈できるか」という観点で判断すると整理しやすくなります。

現場では「多少ステートフルだけれど運用上問題ない」と割り切る判断もあります。
その場合は、負荷分散構成やスケールアウト時の影響をあらかじめ検討しておくことが重要です。

キャッシュ可能性とスケーラビリティ

RESTでは、レスポンスがキャッシュ可能かどうかを明確にすることが推奨されています。(roy.gbiv.com)
キャッシュとは、同じ内容のレスポンスを一時的に保存し、次回以降の応答を高速化する仕組みです。

HTTPには、Cache-Controlヘッダーなどでキャッシュ方針を伝える仕組みがあります。(RFCinfo – RFC中文文档)
例えば、ほとんど更新されないマスターデータの一覧APIなら、クライアントやCDNによるキャッシュを前提に設計すると、負荷とレスポンス時間を大きく減らせることがあります。

実務での判断基準としては、次のような観点が役立ちます。

• 多少古い情報が返っても致命的ではないか
• 更新頻度に比べてアクセス頻度が高いか
• セキュリティ上、キャッシュされると困る内容ではないか

例えば「為替レート」や「在庫数」のように頻繁に変わる情報は、キャッシュ時間を短くする、もしくはキャッシュしない方針を選ぶこともあります。
逆に「都道府県一覧」「業種マスタ」のようなデータは、ある程度長めにキャッシュしても実害が少ない代表例です。

統一インターフェースとHTTPメソッド

RESTの中心的な制約の一つが「統一インターフェース」です。
これは、APIごとにバラバラな設計にせず、一定のルールに従うことでクライアント側の理解コストを下げるという考え方です。(roy.gbiv.com)

HTTPメソッドは、その中核を担う要素です。
代表的なメソッドの意味は次のように整理できます。(MDNウェブドキュメント)

• GET … リソースの取得（副作用のない読み取り）
• POST … 新規作成や処理のトリガー
• PUT … リソースの全体更新（指定された表現で上書き）
• PATCH … リソースの部分更新
• DELETE … リソースの削除

例えば、社員情報を更新するAPIを考えるとします。

• 社員情報の全項目をクライアント側で持っており、毎回丸ごと上書きするなら PUT /employees/123
• メールアドレスだけを変更したいなら PATCH /employees/123

といったように、HTTPメソッドの意味に沿って設計したほうが、後から仕様を読む人にも意図が伝わりやすくなります。

現場では「全部POSTで良くないか」という議論が出ることもあります。
短期的には実装が楽に見えるかもしれませんが、長期的にはクライアントやログ、監査の観点で分かりにくくなりやすいため、メソッドの意味を基本線として扱うのが無難です。

階層化システムとセキュリティの考え方

RESTでは、クライアントは必ずしもサーバーと一対一で直接つながる必要はなく、プロキシやゲートウェイなど複数のレイヤーを挟んでもよいとされています。
これを「階層化システム」と呼びます。(roy.gbiv.com)

この考え方は、現代のAPIアーキテクチャと相性が良く、例えば次のような構成にも自然に当てはまります。

• クライアント → APIゲートウェイ → バックエンドサービス
• クライアント → CDN → アプリケーションサーバー

階層化を前提にすることで、認証やレート制限をゲートウェイに集約するなど、責務を整理しやすくなります。
一方で「どのレイヤーで何をしているのか」が不透明になると、トラブルシュートやセキュリティレビューが難しくなる点には注意が必要です。

実務では、「どのレイヤーがリクエストを終端してレスポンスを返しているのか」「どのレイヤーでTLS終端しているのか」といった情報を、図やドキュメントで共有しておくことがトラブル防止につながります。

実務でRESTを適用するときの判断基準

最後に、実務でRESTをどこまで意識して設計すべきかの判断ポイントを整理します。

経験則として、次のような基準で考えるとバランスが取りやすくなります。

• 外部公開APIや長期運用が前提のAPIほどRESTの原則を重視する
• チーム内だけで短期的に使うAPIでは、RESTの原則と実装コストを天秤にかけて判断する
• RESTの制約をあえて外す場合は、その理由を明文化したうえで合意しておく

例えば、社内向けのバッチ連携用APIで、短期間しか使わない前提なら「とりあえずPOSTで1本のエンドポイントに寄せる」判断も現実的です。
一方で、パートナー企業や外部開発者が利用するAPIは、ドキュメントも含めてRESTの原則に沿っておいたほうが、将来的な拡張や運用がしやすくなる傾向があります。

開発現場では、「RESTという言葉に縛られる」のではなく、「RESTの原則をチェックリストとして使い、合わないところは意図的に外す」というスタンスが取りやすいと言えます。

よくある質問

Q1．RESTとRESTfulは何が違いますか。
一般的には、RESTの制約にかなり忠実に従っている場合に「RESTful」と表現し、RESTの考え方を部分的に取り入れているだけの設計を「REST風」などと呼び分けることがあります。
ただし、明確な業界統一の定義があるわけではありません。

Q2．JSONを返すだけのAPIもRESTですか。
レスポンス形式がJSONであることだけではRESTとは言えません。
URI設計やHTTPメソッドの使い方、ステートレス性などの観点も含めて判断する必要があります。

Q3．RESTよりGraphQLやgRPCのほうが良いのでしょうか。
用途によって向き不向きがあります。
レスポンスの柔軟さや型安全性を重視する場合はGraphQLやgRPCが適することもありますが、既存ブラウザやHTTPインフラとの相性、学習コストなども含めて比較検討するのが現実的です。

Q4．既存の非RESTなAPIをすぐに作り直すべきですか。
現行システムが安定しており、利用者も困っていないなら、優先して改修する必要はないケースも多くあります。
新機能追加や大規模リプレースのタイミングで、RESTの原則を取り入れながら徐々に改善していく方針がよく採られます。

RESTとは？意味と基本原則のまとめ

・RESTはプロトコル名ではなく設計上の制約条件の集合
・リソースとその表現をやり取りするアーキテクチャスタイル
・HTTPと相性が良く多くのREST風APIがHTTP上で実装される
・URIは処理ではなく何のリソースかを表すように設計する
・HTTPメソッドの意味を尊重してGETやPOSTなどを使い分ける
・ステートレス性を意識しリクエストごとに完結する設計を心がける
・キャッシュ可能性を判断し適切にCache関連ヘッダーを設定する
・階層化システムを前提にゲートウェイやCDNなどの役割を整理する
・RESTの制約を全て満たしていなくても現場では段階的に適用される
・RESTかどうかよりも利用者にとって理解しやすいAPIかを重視する
・RESTの原則をチェックリストとして使い外す箇所は理由を明文化する
・外部公開APIほどRESTの原則を丁寧に適用する価値が高い
・短命な社内APIではRESTと実装コストのバランスを考えて決める
・JSONを返しているだけではRESTとは言えないことを意識する
・RESTは目的ではなく読みやすく保守しやすいAPIを作るための道具