CUEIとの実装レベルでの関係 | REST-APIサーバー開発環境

REST-API は、SOCKET-MANAGER Framework の中核である CUEI（Communication / Union / Event / IPC）アーキテクチャの上で動作します。
HTTP リクエスト処理もソケット通信と同じイベント駆動モデルに統合されており、内部的には Event や IPC と密接に連携しながら処理が進みます。

本ページでは、REST-API が CUEI のどの層に位置し、どのように連携して動作するのかを実装レベルの視点から解説します。

統合抽象化レイヤー

CUEI（Communication / Union / Event / IPC）は、SOCKET-MANAGER Framework の中心となる抽象化レイヤーです。

REST-API、WebSocket、TCP、UDP など、異なる通信方式を同じ開発体験で扱えるように統一することを目的としています。

CUEI は以下の4つの要素で構成されます。

● Communication（通信抽象化）
● Union（Context / 共有基盤）
● Event（イベントループ / ステートマシン）
● IPC（サーバー間通信）

REST-API サーバーは、この CUEI の上に構築されており、HTTP 処理・状態遷移・分割送信・スケールアウトなどを統合的に扱えます。

REST-API 全体の概要については▶REST-APIサーバー開発環境（トップページ）を参照してください。

通信方式の統一抽象化

Communication は、以下のような異なる通信方式を統一的に扱うためのレイヤーです。

● HTTP（REST-API）
● WebSocket
● TCP / UDP
● 独自プロトコル

これらの通信方式は内部で抽象化され、イベント処理側ではプロトコルの違いを意識せずに実装できます。

REST-API における役割

REST-API では、Communication 層が以下を担当します。

● HTTP メッセージの受信（PSR-7 準拠）
● RequestWrapper / ResponseWrapper の生成
● Keep-Alive / Connection 管理
● Chunked / SSE / Range の送信制御

これにより、REST-API の実装者は HTTP の細かい仕様を意識せずに、シンプルなコードで API を構築できます。

Context の役割

Union は、REST-API の実行に必要な情報をまとめたContext（共有基盤） を提供します。

Context には以下が含まれます。

● RequestWrapper（HTTP リクエスト）
● ResponseWrapper（HTTP レスポンス）
● IPC 情報（サーバー間通信）
● ユーザー定義パラメータ
● サーバー内部状態

統一 API の利点

Context を使うことで、どのイベント処理でも以下のように統一的にアクセスできます。

$ctx->request()->body();
$ctx->response()->json(['ok' => true]);
$ctx->simple_socket->send(['task' => 'run']);

イベントハンドラ、ステートマシン、IPC など、どの実装方式でも同じ API を使えるため、学習コストが大幅に下がります。

イベントループの役割

Event は、SOCKET-MANAGER の実行モデルを支える仕組みで、以下を担当します。

● イベントループの管理
● コルーチン実行
● 非同期処理の制御
● 長時間接続の管理（SSE / WebSocket）
● コンテキストの FIFO 形式の送受信バッファ制御
● イベント多重起動の防止と処理順序の保証

ステートマシン（UNIT）

ステートマシンは、複雑な処理を状態単位（UNIT）に分割して実行する仕組みです。

REST-API では以下のような用途で利用されます。

● Chunked Transfer の分割送受信
● SSE（Server-Sent Events）の継続送受信
● Range 送受信（部分的なファイル送受信）
● 大容量処理の分割実行

イベントハンドラ型との違い

● イベントハンドラ型 → 単一メソッドで完結する処理
● ステートマシン型 → 状態遷移を伴う処理

どちらも CUEI の Event によって統一的に扱われます。

IPC の役割

IPC は、複数のサーバー間でデータをやり取りするための仕組みです。

● マルチサーバー構成
● 負荷分散
● バックグラウンド処理
● 分散タスク実行

Parallel クラス

IPC は Parallel クラスを通じて利用できます。

$ctx->simple_socket->send(['task' => 'run']);

Launcher と組み合わせることで、サーバー監視・CPU 割り当て・プロセス管理などの DevOps 機能も統合できます。

本ページで紹介した CUEI の各要素が、REST-API とどのように結びついているのかを、最後に簡単に整理します。

REST-API と CUEI 四象限のつながり

CUEI（Communication / Union / Event / IPC）は、4つの要素が互いに連携し合うことで成立する SOCKET-MANAGER Framework の統合基盤です。
REST-API はこのうち Communication（TCP） に属し、クライアント（ユーザー）からの HTTP リクエストを受け取る役割を担います。

一方で、同じサービス（＝1プロセス）内には IPC を担う別モジュール（UDP） が存在し、SocketManager や SimpleSocket を通じて、他のサービスと疎結合に協調します。

下図は、1サービス内における Communication（TCP）と IPC（UDP）の構成例を示したものです。
実際の IPC 構成はプロジェクトの要件に応じて自由に設計できるため、あくまで一例としてご覧ください。

1サービス＝1プロセス内で、TCPモジュールがCommunicationを、UDPモジュールがIPCを担当し、共通のEventとUnionを共有して動作する構造の例

1サービス（＝1プロセス）内で並列に動作する Communication（TCP）と IPC（UDP）モジュールの構造例。
TCP はクライアントと通信し、UDP は他サービスとの協調通信を担当します。

このように、REST-API は CUEI の一部として動作しながら、必要に応じて IPC を通じて外部サービスと連携することで、マイクロサービス構成の一部としても活用できます。

さらに、CUEI に Operation（運用）を加えた CUEI/O では、Launcher がサービスの起動・監視・メトリクス収集などの DevOps 機能を統合的に管理します。
REST-API もこの運用基盤の一部として動作します。

このように、REST-API は CUEI、CUEI/O の仕組みと連携することで、通信・状態管理・協調・運用が一貫したアーキテクチャの上で実現されます。

CUEI そのものの設計思想や四象限モデルについては、▶アーキテクチャ（CUEIの詳細）を参照してください。

【CUEIとの実装レベルでの関係】

はじめに

CUEI とは

統合抽象化レイヤー

Communication