「Web APIとREST」をファミレスの注文でスッキリ理解する
こんにちは！
35歳から未経験でWebを学んでいる者です。
「Web API」や「REST」について、自分なりに理解を整理したのでまとめてみます。
今回は、イメージしやすいように
「ファミレスの注文」に例えて考えてみました。
同じように学習中の方の参考になれば嬉しいです！
この記事はこんな方におすすめ
・「API」という言葉にまだ少し抵抗がある方
・RESTやステートレスの意味がなんとなく曖昧な方
・基礎を一度シンプルに整理しておきたい方
結論（先にシンプルに）
一言でいうと、
API ＝ プログラム専用の「注文窓口」
REST ＝ その窓口での「超スマートな注文ルール」
です！
1. そもそもAPIとは？
API（Application Programming Interface）は
コンピューター同士がやり取りするための「ルール(仕様)」です。
具体例：ファミレスのメニュー表
あなたがファミレスに行ったとしましょう。
厨房のシェフに直接「ハンバーグ作って！」と叫んでも、普通はつまみ出されますよね。
そこで登場するのが「メニュー（API）」です。
メニューには以下の3つが決まっています。
名前： 「Aセット」
パラメータ（引数）： 「ライス大盛りで」
結果（戻り値）： 「ハンバーグと大盛りご飯が届く」
この「何を言えば（入力）、何をしてくれるか（出力）」が決まっている窓口こそがAPIです。
そして、これをインターネット（HTTP）越しに使えるようにしたのが「Web API」です。
2. Web APIでよく使われる設計スタイル「REST（レスト）」
Web APIには「絶対こう作れ！」という厳しい法律はありません。
自由がゆえに、バラバラの分かりにくいAPIが作られてしまうという問題がありました。
そこで「こういうルールで作るとみんな使いやすいよ！」と提案されたのが「REST」という設計の指針です。
RESTのルールを守っているAPIを「RESTful API」なんて呼んだりします。
RESTには、特に大事な4つの特性があります。
① アドレス可能性（住所がある）
すべての情報に「URL」という一意の住所を持たせます。
「あの〜、例のアレください」という曖昧な注文ではなく、
「https://api.example.com/menu/hamburg」
とビシッと指定してアクセスできるようにすることです。
② 統一インターフェース（操作方法が同じ）
やり取りの方法を
「GET（取得）」「POST（作成）」「PUT（更新）」「DELETE（削除）」
などの決まった方法に統一すること。
どこのお店に行っても「注文＝オーダー」「会計＝レジ」と決まっているから迷わないのと同じですね。
③ ステートレス性（過去を振り返らない）
サーバーは「あなたの過去の注文（状態＝ステート）を一切覚えていない」という状態を指します。
【普通の会話（ステートフル）】
客：「ハンバーグください」
店：「はい」
客：「あ、やっぱりさっきの大盛りで」
店：「了解です！（さっきのはハンバーグだな）」
【RESTな会話（ステートレス）】
客：「ハンバーグください」
店：「はい」
客：「あ、やっぱりさっきの大盛りで」
店：「……さっきって何？（記憶喪失）」
RESTな店員には、毎回「ハンバーグを大盛りでください」と必要な情報をすべて伝える必要があります。
こうした理由は、店員（サーバー）がお客さんの注文をいちいち覚えていると、お客さんが増えた時にパンクしてしまうからです。
「過去を覚えない」ことで、どの店員（サーバー）が対応しても同じように処理でき、お店を簡単に大きく（サーバーを増強）できるんです。
④ 接続性（次へのリンクがある）
一つの結果の中に、次に関係する情報へのリンクが含まれていること。
Amazonで商品を買ったら「この商品を買った人はこれも買ってます」とリンクが出るようなイメージです。
3. 図解：Web APIのやり取りイメージ
プログラム同士のやり取りを図で見てみましょう。
【クライアント（あなた）からの注文】
GET /api/v1/users/35age-beginner
Host: example.com
（意味：example.comさん、35歳未経験エンジニアの情報をちょうだい！）
⬇︎
⬇︎（インターネットの荒波を越えて…）
⬇︎
【サーバー（お店）からの返事】
{
"id": 1,
"name": "wata-shoさん",
"status": "学習中",
"comment": "腰と目が痛いです"
}
（意味：はいよ！今のステータスは「学習中」で、腰痛持ちだね！）
こんな感じで、人間にはただの文字列に見えても、コンピューター同士はしっかり会話しているんです。
4. RESTの限界と他のアプローチ
RESTはシンプルで分かりやすい設計ですが、
Webサービスが複雑になるにつれて「少し扱いづらい」と感じる場面も出てきます。
例えば、必要以上のデータが返ってきたり、
複数のAPIを組み合わせないと欲しい情報が取れなかったりするケースです。
こうした課題に対応するために、別のアプローチも使われています。
GraphQL（グラフQL）：
「ハンバーグの肉と、ポテト1本と、コーラ一口だけちょうだい！」というように、
必要なデータだけを柔軟に取得できる仕組み。
RPCスタイル：
遠くのサーバーにある機能を、あたかも自分のパソコンの関数のように呼び出すスタイル。
現在は「REST一択」というわけではなく、
システムに合わせてこれらを使い分けるケースが増えています。
まとめ
Web APIとRESTについて、要点だけ3つにまとめます！
・APIは「プログラム同士がやり取りするための注文窓口」
・RESTは「住所（URL）を決めて、記憶を持たず（ステートレス）、シンプルにやり取りする設計スタイル」
・用途に応じて、GraphQLやRPCなど別のアプローチも使い分けられている
APIの考え方が分かってくると、
普段使っているサービスの裏側も少しずつ見えてきて面白いですね。
それではまた次回の記事で！