レストランのサービス形態で理解する超入門ガイド
API Gatewayの3つのタイプを、身近なレストランのサービス形態で分かりやすく説明します！
お客さん（アプリ） と キッチン（サーバー） の間で、 注文を受け付けて、料理を運ぶ ウェイターのような役割です
お客さん
が
ウェイター
に
「ハンバーガーを1つお願いします」
👨🍳 ウェイターが
キッチン
に注文を伝える
🍔 料理ができたら
お客さん
に運ぶ
アプリ
が
API Gateway
に
「ユーザー情報を取得して」
🖥️ API Gatewayが
サーバー
にリクエストを転送
📊 データが返ってきたら
アプリ
に配信
豊富なサービス
が特徴です。
ソムリエ、コンシェルジュ、専門スタッフが揃っていて、
あらゆる
おもてなし
を提供してくれます。
シンプル・早い・安い
が特徴です。
基本的なサービスに特化して、
素早く・お手頃価格
で提供します。
リアルタイム双方向
が特徴です。
お客さんとスタッフが常に繋がっていて、
即座にやり取り
できます。
💰 料金: やや高め（月100万リクエストで約$3.5）
⚡ 速度: 標準的
✅ メリット:
💰 料金: 格安（月100万リクエストで約$1）
⚡ 速度: 高速
🎯 適用例:
💰 料金: 接続時間ベース
⚡ 速度: 瞬時
フルサービス・高機能
シンプル・高速・現代的
リアルタイム専用
🔄 既存システムの移行:
🎯 新規開発なら:
クライアント
ウェブアプリ・モバイルアプリAPI Gateway
注文受付・認証・転送バックエンド
Lambda・EC2・データベースお客さん → ウェイター（注文確認・会員チェック） → キッチン → 料理完成 → ウェイター → お客さん
チャット・ゲーム・ライブ配信
を作りたい？
→ YES なら
WebSocket API
一択！
→ NO なら 次のステップへ
大企業・金融・医療など厳格な要件
がある？
→ YES なら
REST API
（豊富な機能）
→ NO なら 次のステップへ
開発速度・コスト・パフォーマンス
を重視？
→ YES なら
HTTP API
（70%安い）
→ 機能重視なら
REST API
新規開発:
HTTP API から始めて、必要に応じて移行
既存システム:
現在 REST API なら、HTTP API に移行検討
両方使い:
用途に応じて使い分けも可能
メリット:
豊富な機能・企業向け機能・実績
デメリット:
高コスト・設定複雑・起動遅い
メリット:
70%安い・2倍高速・シンプル設定
デメリット:
機能制限・新しいサービス
メリット:
リアルタイム・双方向・低遅延
デメリット:
用途限定・接続管理複雑
🏪 REST API = 高級レストラン（豊富な機能・エンタープライズ向け・高価格）
🥪 HTTP API = カジュアルカフェ（70%安い・2倍高速・シンプル）
💬 WebSocket API = チャット接客（リアルタイム・双方向・特殊用途）
🎯 初心者へのおすすめ：
💡 迷ったら： HTTP API で始めて、必要に応じて機能追加・移行を検討しましょう！
Created by SSuzuki1063
AWS SAP Learning Resources