RESTって何?わかりやすく解説

「APIって聞いたことあるけど、RESTって何?」「Webサービスを作りたいんだけど、REST APIって絶対必要なの?」そんな疑問を持ったことはないかな。プログラミングを始めてちょっとすると、ほぼ確実にこの「REST」という言葉に出会うんだよね。でも調べてみると難しい英語ばかりで「もうわからん」ってなりがち。この記事を読めば、RESTが何なのか、なぜ使われているのか、スッキリわかるよ。

「REST API」ってよく聞くんだけど、RESTって何のこと?

RESTは「Representational State Transfer」の略で、つまり「Webサービス同士が情報をやりとりするときのルールの決め方」のことだよ。ルールそのものじゃなくて、「こういう考え方でルールを作ろう」という設計スタイルなんだ。
設計スタイルって、具体的にどういうこと?

たとえば図書館のルールで考えてみよう。「本を借りるときはカウンターに持っていく」「返すときは返却ボックスへ」みたいに、操作ごとに決まった方法があるよね。RESTも同じで、「データを取るときはこのやり方、データを作るときはこのやり方」という統一ルールでWebの情報をやりとりするんだよ。
じゃあ、なんでRESTが広まったの?別の方法じゃダメだったの?

以前は「SOAP」という複雑なやり方が主流だったんだけど、設定が大変だったんだ。RESTは普通のWebブラウザと同じ仕組み(HTTP)を使うから、シンプルで誰でも使いやすい。だから世界中のサービスがRESTを採用するようになったんだよ。
TwitterとかYouTubeのAPIもRESTなの?

そう!ほとんどの有名サービスのAPIはRESTスタイルで作られてるよ。TwitterのAPI、Google Maps API、GitHubのAPIも全部REST。だからRESTを理解しておくと、いろんなサービスのAPIを使いこなせるようになるんだ。
📝 3行でまとめると
  1. RESTはWebサービス同士が情報をやりとりするための 設計スタイル(考え方のルール) のこと
  2. 普通のWebと同じ HTTP という仕組みを使うから、シンプルで世界中に広まった
  3. Twitter・YouTube・GitHubなど ほぼすべての有名APIがRESTスタイル で作られている
目次

もうちょっと詳しく

RESTはロイ・フィールディングという人が2000年に提唱した考え方で、正式には「アーキテクチャスタイル」、つまり「システムの設計思想」と呼ばれるものだよ。具体的には「URLでリソース(データのこと)を表す」「HTTPメソッドで操作を区別する」「やりとりは毎回独立させる(ステートレス)」などのルールに従って設計するんだ。これに従って作られたAPIのことを「REST API」や「RESTful API」と呼ぶよ。RESTfulの「ful」は「〜らしい」という意味で、つまり「RESTの考え方に忠実に作られたAPI」ということ。厳密にはRESTとRESTful APIは別の意味だけど、現場ではほぼ同じ意味で使われることがほとんどだよ。

💡 ポイント
RESTは「仕様書」じゃなくて「考え方」。だから完全に同じ実装が存在するわけじゃないよ!

⚠️ よくある勘違い

❌ 「RESTはプログラミング言語やツールの名前だ」
→ プログラミングを始めたばかりだとREST=何かのソフトや言語だと思いがち
⭕ 「RESTは設計の考え方(スタイル)の名前」
→ 特定の言語やツールではなく、PythonでもJavaScriptでも「RESTスタイルで作る」ことができるルールセットのこと
なるほど〜、あーそういうことか!

[toc]

RESTって何?まず「API」から理解しよう

APIとは「サービス同士をつなぐ窓口」

RESTを理解するには、まず「API」を知る必要があるよ。APIとは「Application Programming Interface」の略で、つまり「アプリやサービスが外部と情報をやりとりするための窓口」のことだ。

身近な例で考えてみよう。レストランに行ったとき、お客さんは直接キッチンに入って料理を作るわけじゃないよね。店員さんに「ハンバーグセットください」と伝えると、店員さんがキッチンに伝えて料理が出てくる。この「店員さん」がAPIのイメージだよ。

たとえばGoogleマップを自分のWebサイトに埋め込むとき、みんなはGoogleのコンピューターに直接アクセスするわけじゃない。Google Maps APIという「窓口」を通じてデータを受け取っているんだ。このやりとりをするときの設計スタイルがRESTということ。

WebサービスはAPIだらけ

実は現代のWebサービスは、ものすごい数のAPIでつながっているんだ。たとえばメルカリで商品を買うとき、裏では「在庫確認API」「決済API」「住所確認API」「通知API」などが連携してる。これらのAPIが全部RESTスタイルで作られていると、開発チームが変わっても同じルールで話せるから、チームワークがスムーズになるんだよ。

RESTの4つの基本ルールを知ろう

ルール1:URLでデータの「場所」を表す

RESTでは、扱うデータのことを「リソース」と呼ぶよ。リソースとは「資源・素材」という意味で、ここではAPIで扱うひとつひとつのデータのことを指す。そしてリソースはURLで表すのがRESTのルールだ。

例えばこんな感じ:

  • https://api.example.com/users → ユーザー一覧
  • https://api.example.com/users/5 → ID番号5番のユーザー
  • https://api.example.com/users/5/posts → 5番ユーザーの投稿一覧

URLを見ただけで「どのデータにアクセスしようとしているか」がわかる。これが「わかりやすいAPIを作る第一歩」なんだよ。

ルール2:HTTPメソッドで「操作の種類」を伝える

データに対して「何をしたいか」は、HTTPメソッドという種類で区別するよ。HTTPメソッドとは「Webでデータを送るときの操作の種類名」のことで、主に4種類が使われる:

  • GET:データを取得する(読む)→ 図書館で本を「借りる」イメージ
  • POST:新しいデータを作る(書く)→ 図書館に本を「寄付する」イメージ
  • PUT / PATCH:既存のデータを更新する(直す)→ 本の情報を「書き直す」イメージ
  • DELETE:データを削除する(消す)→ 本を「廃棄する」イメージ

この4つをまとめて「CRUD」(クラッド)と呼ぶこともある。Create(作る)・Read(読む)・Update(更新する)・Delete(消す)の頭文字だよ。データを扱う基本操作がこの4種類でカバーできるんだ。

ルール3:ステートレスにする

ステートレス」とは、つまり「毎回のやりとりが完全に独立している」という意味だよ。サーバー側は「前回どんなリクエストがあったか」を覚えていない。

コンビニのセルフレジをイメージしてみよう。セルフレジはあなたが「昨日も来たお客さんだな」なんて覚えてないよね。毎回、バーコードをスキャンして、支払いして、終わり。次のお客さんも同じように対応する。これがステートレスのイメージ。

なぜこれが大事かというと、サーバーがシンプルになるから。複数のサーバーに処理を分散させるときも「どのサーバーが過去の情報を持ってるか」を気にしなくていいので、大規模なサービスを作りやすくなるんだよ。

ルール4:統一インターフェース

どのリソースにアクセスするときも、同じルールで操作できる。これを「統一インターフェース」というよ。インターフェースとは「操作するための接点」という意味。

テレビのリモコンで考えてみよう。どのメーカーのテレビでも「電源ボタン、チャンネルボタン、音量ボタン」という共通の操作方法があるよね。同じように、RESTでは「どのAPIでもGET・POST・PUT・DELETEで操作できる」という統一されたルールがある。だからAPIが変わっても、操作の仕方を一から覚え直す必要がないんだ。

実際の通信でどうやって動くの?

リクエストとレスポンスの流れ

REST APIを使った通信は、大きく「リクエスト(お願い)」と「レスポンス(返事)」の2段階で動いているよ。

例えばスマホのアプリで「ユーザー情報を表示する」場合:

  1. アプリ(クライアント)が GET https://api.example.com/users/5 とリクエストを送る
  2. サーバーが「ID5番のユーザー情報をください」という意味だと理解する
  3. サーバーがデータベースから情報を取り出す
  4. サーバーがJSONというデータ形式でレスポンスを返す
  5. アプリがデータを受け取って画面に表示する

このやりとりが、1回の操作で完結するよ。ステートレスだから、次の操作でもまた同じようにリクエスト→レスポンスが行われる。

JSONってどんな形式?

REST APIのレスポンスでよく使われるのが「JSON(ジェイソン)」というデータ形式だよ。JSONとは「JavaScript Object Notation」の略で、つまり「テキストでデータをわかりやすく表現する書き方」のこと。

実際はこんな感じで返ってくる:

{
  "id": 5,
  "name": "田中太郎",
  "age": 15,
  "email": "tanaka@example.com"
}

人間にも読みやすくて、プログラムでも扱いやすい形式なんだ。鍵と値のペアで書くところは、辞書(dictionary)みたいなイメージだよ。

REST APIを使う側・作る側の視点

使う側(クライアント)の視点

プログラムからREST APIを使うときは、ざっくりこんな手順になるよ:

  • APIのドキュメントを読んで、URLとメソッドを確認する
  • 必要なら認証(APIキーなど)の設定をする
  • コードでHTTPリクエストを送る
  • 返ってきたJSONデータを処理する

PythonでいえばRequestsライブラリ、JavaScriptならfetch関数を使えば、たった数行でAPI呼び出しができちゃう。最初は難しそうに見えるけど、実際にやってみると意外とシンプルなんだよ。

作る側(サーバー)の視点

REST APIを自分で作るときは「エンドポイント」を設計するのが最初の仕事だよ。エンドポイントとは「APIにアクセスするためのURLと操作の組み合わせ」、つまり「窓口の種類」のことだ。

例えばブログサービスのAPIを設計するとしたら:

  • GET /articles → 記事の一覧を取得
  • GET /articles/1 → ID1番の記事を取得
  • POST /articles → 新しい記事を作成
  • PUT /articles/1 → ID1番の記事を更新
  • DELETE /articles/1 → ID1番の記事を削除

このようにURLとHTTPメソッドの組み合わせで、「何をどうするか」が明確に表現できるのがRESTの強みなんだ。チームで開発するとき、「このAPIは何をするの?」という会話が減って、ドキュメントを見ればすぐわかるようになるよ。

RESTのメリットと、知っておきたい限界

RESTが広まった3つの理由

RESTが世界中のWebサービスで使われるようになった理由は大きく3つあるよ:

  • シンプルさ:HTTPという既存の仕組みをそのまま使うから、新しいプロトコルを覚える必要がない
  • スケールしやすい:ステートレスなので、サーバーを増やしやすく大規模なサービスに向いてる
  • どんな言語でも使える:HTTPを扱えれば言語を選ばないから、フロントエンドもバックエンドも同じAPIを使える

スマホアプリもWebブラウザも、同じREST APIを叩けばいい。だからサーバー側は1種類のAPIを作るだけで、複数のクライアントに対応できるんだよ。これは開発コストを大幅に下げてくれるんだ。

RESTにも苦手なことがある

RESTは万能じゃないよ。例えばSNSのフィード画面を作るとき、「ユーザー情報」「投稿一覧」「いいね数」「コメント数」を全部表示したい場合、RESTだと複数回APIを呼ぶ必要が出てくることがある。これを「オーバーフェッチング(必要以上にデータを取りすぎること)」や「アンダーフェッチング(1回では足りなくて何度も呼ぶこと)」という問題と呼ぶよ。

そういった問題を解決するために「GraphQL(グラフQL)」というRESTとは別の設計スタイルも生まれた。GraphQLとは「必要なデータだけを1回のリクエストで取れるAPIの設計スタイル」のことで、FacebookやGitHubも採用してるよ。RESTとGraphQLはどちらが優れているというより、用途によって使い分けるものだと覚えておこう。

それでも2026年現在、圧倒的多数のAPIはRESTスタイルで作られていて、プログラミングを学ぶ上で絶対に知っておくべき知識であることは変わらないよ。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

大人になってから「これ知らなかった…」と恥ずかしい思いをした経験から、このサイトを作りました。お金・仕事・社会のしくみって、学校で教えてくれないのに知らないと損することだらけ。むずかしい言葉を「あーそういうことか!」って思えるまでかみ砕いて説明するのが得意です。主に経済・法律・税金・ライフイベント周りの用語を毎日更新中。

目次