RESTとRESTfulの違い

用語	定義	特徴
REST	HTTPベースのアーキテクチャスタイル）	ステートレス・リソース指向・HTTPメソッドの正しい使い分けなど6原則がある
RESTful API	RESTの原則を厳密に守ったAPI	URIは名詞、メソッドは意味に沿って使い分け、HATEOAS対応など
REST API	RESTっぽい構成をしたAPI	一部REST原則を採用した設計。多くは「HTTP＋JSON＋URI」でOKとされる
RESTライク API	実用性を優先した現実的なAPI	POST中心、操作名をURIに含める、RPC風などが特徴

なぜゲームではRESTfulにしないのか？

理由	詳細
パフォーマンス重視	HTTPメソッドの切り替え・ヘッダのオーバーヘッドを嫌い、POST一本化
状態あり通信が基本	ゲームでは状態（セッション、ターン、部屋）に基づいた処理が多い
チート防止	サーバー側で状態を管理して、クライアントにロジックを持たせない
プラットフォーム制約	一部環境ではPUTやDELETEが使えないため、POSTだけで済ませる設計が多い
gRPC/WebSocketの採用増	高速・軽量・双方向な通信の必要性によりHTTPベース設計を脱却する傾向も

状態・セッションを前提としたAPI設計

特徴

• サーバーが一時的な情報（セッション状態）を保持
• 各リクエストはその状態に依存して意味を持つ
• クライアントが単独で完結できない（REST原則に反する）

代表的な例

シーン	状態の例
バトル進行	HP、バフ、行動履歴、敵状態など
マッチメイキング	ルーム状態、人数、参加状況など
ガチャ演出	抽選結果の保持と段階的開示
チャット	同一接続中のログや未読管理

ハイブリッド設計

機能	使用する通信方式
アカウント登録、課金、ガチャ	REST or RESTライクなHTTP API
バトル、チャット、通知	WebSocket（またはgRPC）
リーダーボード取得、履歴確認	REST（キャッシュ・静的情報に向く）

全体のまとめ

項目	RESTful	RESTライク	WebSocket
設計哲学	アーキテクチャ的厳密さ	実用性重視の妥協設計	リアルタイム性重視
状態管理	基本NG（ステートレス）	軽度の状態依存あり	状態前提で動作
通信方向	クライアント→サーバーのみ	同上	双方向（イベントPush可能）
ゲームとの相性	△（メニュー系のみ適合）	◎（多くのゲームで採用）	◎（同期・対戦に最適）
採用例	Web公開API、ドキュメント化されたサービス	ソシャゲ、PlayFabなど	Unity + Photon、Firebaseなど