API・メッセージング

REST API れすとえーぴーあい

HTTPWeb APIJSONエンドポイントリソースステートレス

REST APIについて教えて

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

Webサービス同士が「共通のお作法」で会話するための仕組みだよ！「この住所（URL）にこのお願い（GET/POSTなど）を送ると、このデータ（JSON）が返ってくる」っていうルールで動いてるんだ。アプリとサーバーの間の”標準語”みたいなもの！

REST APIとは

REST APIとは、Webシステム同士がデータをやり取りするための「設計スタイル＋通信のお作法」のことです。RESTは「REpresentational State Transfer（表現状態転送）」の略で、2000年にロイ・フィールディング氏が博士論文の中で提唱したアーキテクチャスタイルです。APIは「Application Programming Interface」の略で、ソフトウェア同士が会話するための窓口のこと。つまりREST APIは、「RESTというルールに従った、システム間の窓口」です。

身近な例で言えば、天気予報アプリがスマホに天気を表示できるのは、気象データを持つサーバーにREST APIで問い合わせているから。楽天やAmazonの商品情報を他のサイトに表示する「外部連携」も、多くがREST APIを使っています。現代のWebサービスのほとんどが、何らかの形でREST APIに依存していると言っても過言ではありません。

ビジネスの現場では、「システムA（既存の基幹システム）」と「システムB（新しいSaaS）」をつなぐ際に「REST APIで連携できますか？」という会話が頻繁に登場します。APIが公開されているかどうかは、システム選定・発注の際の重要な確認ポイントのひとつです。

RESTの5つの核心：どんなルールで動いているの？

RESTには設計上の原則（制約）があります。これを守って作られたAPIを「RESTful API」と呼びます。

原則	意味	実務上のイメージ
統一インターフェース	決まった方法（HTTPメソッド）でやり取りする	メニューが統一されたファストフード
ステートレス	サーバーは前の会話を覚えない	毎回「初対面」として話しかける
クライアント・サーバー分離	画面側とデータ側を分けて作る	フロントとバックの独立
キャッシュ可能	同じ回答は使い回してよい	よくある質問はFAQで済ませる
階層化システム	中継サーバーを挟んでもOK	電話が交換機を通っても問題ない

HTTPメソッド：「お願いの種類」は4種類

REST APIでは、URLで「どのデータか」を指定し、HTTPメソッドで「何をしたいか」を伝えます。これが「CRUD操作」と対応しています。

操作の種類（CRUD）   HTTPメソッド    例：ユーザー情報への操作
─────────────────────────────────────────────────────────────
Create（作成）    →  POST      →  POST   /users        （新規登録）
Read  （読取）    →  GET       →  GET    /users/123    （ID:123を取得）
Update（更新）    →  PUT/PATCH →  PUT    /users/123    （ID:123を更新）
Delete（削除）    →  DELETE    →  DELETE /users/123    （ID:123を削除）

レスポンスの形：JSONってなに？

REST APIのデータのやり取りには、主にJSON（JavaScript Object Notation）という形式が使われます。人間にも読みやすい、シンプルなテキスト形式です。

{
  "id": 123,
  "name": "山田太郎",
  "email": "yamada@example.com",
  "department": "営業部"
}

歴史と背景

2000年 — ロイ・フィールディングが博士論文でRESTを提唱。当時はSOAPという重厚なAPIが主流だった
2002〜2004年 — Amazon・eBayがREST APIを外部公開。開発者に「シンプルなAPIって便利！」と広まり始める
2006〜2010年 — Twitter・Facebook・GoogleがREST APIを提供。スマートフォンアプリとの連携需要が爆発的に増加
2010年代前半 — REST APIがWeb開発のデファクトスタンダード（事実上の標準）に。SOAPはレガシーシステムに追いやられる
2015年頃〜 — GraphQL（Facebookが開発）が登場し、「REST vs GraphQL」の議論が始まる。RESTは依然として圧倒的多数派
現在 — クラウドサービス（AWS・Azure・Salesforceなど）のほぼすべてがREST APIを提供。システム間連携の”共通語”として定着

SOAP・GraphQL・WebSocketとの比較

REST APIの立ち位置を、他のAPI方式と比べてみましょう。

比較項目	REST API	SOAP	GraphQL	WebSocket
覚えやすさ	◎ シンプル	△ 複雑	○ 慣れが必要	○
データ形式	JSON（主流）	XML	JSON	任意
通信方向	一方向（要求→応答）	一方向	一方向	双方向
向いている用途	Webサービス全般	金融・官公庁の連携	複雑な検索・SNS	チャット・リアルタイム
普及度	◎ 最多	△ 減少傾向	○ 増加中	○ 特定用途

REST APIとSOAPのシステム上の違いをざっくり図にすると、こんなイメージです。

規格・RFC番号	内容
RFC 7230〜7235	HTTP/1.1の仕様（RESTのベースプロトコル）
RFC 7540	HTTP/2の仕様（REST APIの高速化に活用）
RFC 8259	JSONのデータフォーマット仕様
RFC 6749	OAuth 2.0（REST APIの認証認可に広く使われる）
OpenAPI Specification（旧Swagger）	REST APIの定義・ドキュメント記述の事実上の標準