Resource Oriented PHP Framework

BEAR.Sunday

Webの原則を、アプリケーションの内側まで。

一つの ResourceObject が、Web API・HTML・コンソール・AIの道具・ドキュメントになる。 書く場所は一つ。出口ごとに、作り直さない。

Quick Startビジネス向けに見る
HTTP API
HTML Page
Console
Composer package
CLI / Homebrew
AI-readable docs

Why it all connects

関係を宣言する。あとは、ついてくる。

BEAR.Sundayは、Webの原則(REST)をアプリケーション全体の設計制約にするPHPフレームワークです。 リンクや埋め込みで「リソース間の関係」を宣言すると、意図(What)と実行(How)が分かれます。 だから次のものが、後付けの機能ではなく構造から生まれます。

Web原則から見る

関係を宣言する(URI・リンク・埋め込み)

↓ What(意図)と How(実行)を分離

透過的な並列実行

埋め込みは関係の宣言。実行戦略はModuleで差し替え。

AIの道具

URI・型・スキーマが、そのままツール定義になる。

複数の表現

同じ状態から HTML・JSON・CLI・ドキュメント。

長期互換

意味はリソースに残り、詳細は外側で替える。

Architecture

REST、DI、AOPを設計の制約にする。

BEAR.Sundayは、フルスタックの便利箱ではなく、アプリケーションの形を保つフレームワークです。 ライブラリは選べる。制約は揺れない。その分、コードの意味が長く残ります。

Resource

すべてを URI で扱う

ページ、API、内部処理を ResourceObject として表現。GET / POST / PUT / DELETE の統一インターフェイスで、何を扱っているのかがコードから追えます。

DI

依存は外から注入する

Ray.Di によるコンパイル時の依存解決で、実行時のサービスロケータやグローバル状態に頼らない構造を保ちます。

AOP

横断的関心を分離する

ログ、キャッシュ、トランザクションなどを Ray.Aop で分離。ビジネスロジックの輪郭を曖昧にしません。

設計を詳しく見る

Value

技術的特徴を、持続する価値へ。

BEAR.Sundayの価値は、便利機能の多さではなく、設計制約が長く効き続けることにあります。 Resource、context-agnostic DI、AOP、CDN中心のRead Modelが、開発、利用体験、ビジネス継続性へ 同じ構造から価値を届けます。

もたらす価値を見る

開発者

Resource、DI、AOP、Contextが責務を分け、実行モード分岐や暗黙の依存を追わずにビジネスロジックへ集中できます。

ユーザー

本質的に静的なRead ModelをCDN、ETag、304へ接続し、速く安定した応答を届けます。

ビジネス

後方互換性、標準技術、CDN中心設計により、移行、保守、運用の継続コストを下げます。

Technical features

技術的な特徴が、設計の制約になる。

BEAR.Sundayは、抽象的な設計思想だけのフレームワークではありません。 実行時性能、キャッシュ、並列実行、ドキュメント生成まで、技術的な特徴がアプリケーションの構造に直結します。

Context-agnostic DI

contextは組み立て時だけ使われ、生成後のオブジェクトはAPP_DEBUGや実行モードを参照しません。

イベントドリブンキャッシュ

TTLだけに頼らず、変更イベントからサーバーとCDNの依存キャッシュ、ETagを連鎖的に無効化します。

CDN Read Model

PHPが生成したHTTP表現をCDNにmaterializeし、変更がない限りCDNから配信し続けます。

HTTPの壁なしの統合

複数アプリケーションをnamespaceとDI bindingで統合し、通信境界を作らずに独立性を保ちます。

ポータブルリソース

BEAR.Sundayで作ったリソースはpackageとして取り込み、他のPHPアプリケーションからURIで呼び出せます。

透過的な並列実行

URIがWhatを表し、HowをModuleへ隠蔽するため、埋め込みリソースの並列実行へコード変更なしで移行できます。

Application as Documentation

ApiDoc HTML、OpenAPI 3.1、JSON Schema、llms.txtへ接続し、実装から読めるドキュメントを生成できます。

技術的特徴を見る

AI-ready architecture

AI時代に強いのは、推測しなくていいコード。

AIエージェントが設計を読み、変更し、レビューする時代には、暗黙の規約よりも 宣言性、明示性、トレーサビリティが価値になります。BEAR.Sundayはそれを アプリケーションの構造として持ちます。

AI時代の価値を読む

宣言性

入力、リンク、表現、キャッシュ方針を属性やスキーマで宣言。AI は暗黙の分岐を推測するより、宣言された意味を読み取れます。

明示性

ResourceObject の onGet / onPost、コンストラクタ注入、context module の束縛が、アプリケーションの実際の境界を明示します。

トレーサビリティ

URI、HAL リンク、JSON Schema、OpenAPI、llms.txt が同じ意味モデルにつながり、変更理由と影響範囲を追跡しやすくします。

Traceable by design

変更の影響を、リソースからたどる。

URI、リンク、埋め込み、スキーマ、context module。アプリケーションの意味を 複数の場所に散らさず、たどれる単位として保ちます。

  • 後方互換性を壊さない、予測可能な進化
  • HTTP、HAL、JSON Schema、PSR など標準技術への接続
  • context string による環境差分の注入
  • CDN、ETag、304を含む Web本来のキャッシュ設計

request

GET app://self/user?id=1

resource

User::onGet(int $id): static

representation

HAL / HTML / JSON / CLI

documentation

OpenAPI 3.1 / JSON Schema / llms.txt

In code

リソースは、状態を決めるだけ。

表現はレンダラーへ、依存はDIへ、横断的関心はAOPへ。クラスの責務を狭く保つことで、 テストもレビューもAIによる解析も素直になります。

実装例を見る
<?php

namespace MyVendor\Project\Resource\Page;

use BEAR\Resource\Annotation\Link;
use BEAR\Resource\ResourceObject;

final class Profile extends ResourceObject
{
    #[Link(rel: 'orders', href: 'app://self/orders?user_id={id}')]
    public function onGet(int $id): static
    {
        $this->body = [
            'id' => $id,
            'name' => 'BEAR.Sunday',
        ];

        return $this;
    }
}

Start small

まずは1つのリソースから。

Composerで雛形を作り、最初の Page Resource を書く。Webでもコンソールでも同じ意味を持つ 小さな単位から、長く育つアプリケーションを始められます。

Quick start

VENDOR=MyVendor PACKAGE=MyProject \
composer create-project bear/skeleton my-project

cd my-project
php bin/page.php get /hello
Quick Startllms-full.txt