はじめに
SOCKET-MANAGER Framework の REST-API は、CUEI アーキテクチャの上に構築された統一的な通信モデルを採用しています。
REST-API と WebSocket/TCP/UDP は同一プロセス内で自然に共存でき、通信方式の違いに依存しない柔軟な API 設計が可能です。
本ページでは、REST-API がどのような思想と構造のもとに設計されているか、また CUEI 全体の中でどの位置づけにあるのかを概念的に解説します。
フレームワークの思想
外部依存を排除した基盤
SOCKET-MANAGER Framework は、Composer パッケージや外部ミドルウェアに依存せず、 フレームワーク単体で動作することを前提に設計されています。
これにより、環境差異や依存関係によるトラブルを最小化し、 安定した運用が可能になります。
CUEI による統一抽象化
通信方式や実装方式の違いを吸収し、どのプロトコルでも同じ開発体験を提供するために CUEI（Communication / Union / Event / IPC） を採用しています。
REST-API もリアルタイム通信も、同じ抽象化レイヤーの上で統一的に扱えます。
REST-API に強い構造
PSR-7 準拠の HTTP 処理、ステートマシンによる確実な分割送信、 IPC によるスケールアウトなど、REST-API に必要な機能を フレームワーク本体にビルトインしています。
アーキテクチャ概要
リクエスト受信
HTTP メッセージを PSR-7 準拠で受信し、RequestWrapper によって扱いやすい形に変換します。
ルーティング処理
URL・HTTP メソッド・正規表現・名前付きパラメータなどを基に、 適切なイベント処理（イベントハンドラ型 / ステートマシン型）へ振り分けます。
イベント処理実行
イベントハンドラ型では単一メソッドで処理を完結させ、 ステートマシン型では UNIT（状態）単位で処理を分割します。
レスポンス生成
ResponseWrapper により、text / json / file / chunked / SSE / Range など、 多様なレスポンス形式を統一 API で扱えます。
イベントループとコルーチン
内部ではイベントループが動作し、非同期処理や長時間接続を効率的に管理します。
CUEI アーキテクチャ
Communication
TCP / UDP / WebSocket / HTTP / 独自プロトコルを統一的に扱う通信抽象化レイヤーです。
REST-API もこの Communication 層の上に構築されています。
Union（Context）
RequestWrapper / ResponseWrapper / IPC 情報などをまとめた共有基盤です。
どのイベント処理でも同じ API でアクセスできるため、実装がシンプルになります。
Event
イベントループ・ステートマシン・コルーチンを統合した実行モデルです。
Chunked / SSE / Range など、状態遷移を伴う API を安定して実現します。
IPC
サーバー間通信を行う仕組みで、Parallel クラスを通じて マルチサーバー構成や分散処理を実現します。
CUEI と REST-API の親和性
Context による統一 API
RequestWrapper / ResponseWrapper を通じて、 どのイベント処理でも同じ API で HTTP を扱えます。
ステートマシンによる高度処理
Chunked Transfer の確実な分割送信、SSE の再接続対応、Range 送信など、 一般的なフレームワークでは難しい処理を安定して実現します。
IPC によるスケールアウト
マルチサーバー構成での負荷分散や、Launcher との連携による サーバー監視・制御が可能です。
Launcher との統合
DevOps 向けの SOCKET-MANAGER Launcher と連携し、 サーバーリソース監視・CPU 割り当て・サービス制御などを統合的に管理できます。