Resource
Everything is identified by URI
Pages, APIs, and internal processes are all expressed as ResourceObjects. With a uniform interface of GET / POST / PUT / DELETE, you can trace what each piece of code handles directly from the code itself.
Resource Oriented PHP Framework
BEAR.Sunday
Web principles, all the way inside your application.
One ResourceObject becomes a Web API, HTML page, console tool, AI instrument, and documentation. Write it once. Don't rebuild for every output.
Core idea
Because Everything is a Resource.
GET app://self/article?id=42
→ HTML ・ JSON(HAL) ・ CLI ・ Tool Use ・ OpenAPI
Same URI, different representations.
HTTP API
HTML Page
Console
Composer package
CLI / Homebrew
AI-readable docs
Why it all connects
Declare the relationships. Everything else follows.
BEAR.Sunday is a PHP framework that makes Web principles (REST) the design constraint for your entire application. When you declare relationships between resources through links and embeds, intent (What) and execution (How) are separated. As a result, the following emerge from the structure itself—not as bolt-on features.
See through Web principlesDeclare relationships (URI, links, embeds)
↓ Separate intent (What) from execution (How)
Transparent parallelism
Embeds are relationship declarations. Execution strategy is swapped via Module.
AI instruments
URIs, types, and schemas become tool definitions as-is.
Multiple representations
Same state → HTML, JSON, CLI, documentation.
Long-term compatibility
Meaning stays in resources; details change on the outside.
Architecture
REST, DI, and AOP as design constraints.
BEAR.Sunday is not a full-stack convenience box. It is a framework that preserves the shape of your application. You choose the libraries. The constraints don't waver. That keeps meaning in your code for the long haul.
DI
Dependencies are injected from outside
Ray.Di resolves dependencies at compile time, maintaining a structure free from runtime service locators and global state.
AOP
Cross-cutting concerns are separated
Logging, caching, transactions, and more are separated using Ray.Aop. Business logic stays clean and well-defined.
Value
Technical features into lasting value.
BEAR.Sunday's value lies not in the number of convenience features, but in how its design constraints remain effective over time. Resource, context-agnostic DI, AOP, and CDN-centric Read Models deliver value to development, user experience, and business continuity from the same structure.
See the valueDevelopers
Resource, DI, AOP, and Context separate responsibilities, letting you focus on business logic without chasing execution mode branches or implicit dependencies.
Users
Inherently static Read Models connect to CDN, ETag, and 304, delivering fast, stable responses.
Business
Backward compatibility, standard technologies, and CDN-centric design reduce the ongoing costs of migration, maintenance, and operations.
Technical features
Technical features that become design constraints.
BEAR.Sunday is more than abstract design philosophy. From runtime performance, caching, and parallel execution to documentation generation, its technical features directly shape the application's structure.
Context-agnostic DI
Context is only used during assembly. Once created, objects do not reference APP_DEBUG or execution mode.
Event-driven caching
Rather than relying solely on TTL, change events cascade-invalidate dependent caches and ETags across server and CDN.
CDN Read Model
PHP generates HTTP representations that are materialized to CDN and served from there until a change event occurs.
Integration without HTTP walls
Multiple applications are integrated via namespace and DI binding, maintaining independence without creating communication boundaries.
Portable resources
Resources built with BEAR.Sunday can be packaged and called via URI from other PHP applications.
Transparent parallel execution
URIs represent What, while How is hidden in Modules. This allows switching to parallel execution of embedded resources without changing any resource code.
Application as Documentation
Connect to ApiDoc HTML, OpenAPI 3.1, JSON Schema, and llms.txt to generate documentation that can be read from the implementation itself.
AI-ready architecture
In the AI era, code that doesn't require guessing wins.
In an age where AI agents read, modify, and review code, declarativity, explicitness, and traceability are more valuable than implicit conventions. BEAR.Sunday has these built into the application structure.
Read about value in the AI eraDeclarative
Input, links, representations, and caching strategies are declared through attributes and schemas. AI can read declared meaning rather than inferring from implicit conventions.
Explicit
ResourceObject's onGet / onPost, constructor injection, and context module bindings make the actual boundaries of the application explicit.
Traceable
URIs, HAL links, JSON Schema, OpenAPI, and llms.txt all connect to the same semantic model, making it easy to trace the reasons for changes and their impact.
Traceable by design
Trace the impact of changes, starting from the resource.
URIs, links, embeds, schemas, and context modules. The meaning of your application is kept in traceable units rather than scattered across multiple places.
- Predictable evolution without breaking backward compatibility
- Connection to standard technologies: HTTP, HAL, JSON Schema, PSR
- Environment differences injected via context strings
- Web-native cache design including CDN, ETag, and 304
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
A resource only decides its state.
Representation goes to the renderer, dependencies to DI, cross-cutting concerns to AOP. Keeping class responsibilities narrow makes testing, reviewing, and AI-assisted analysis straightforward.
See code examples<?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
Start with a single resource.
Create a skeleton with Composer and write your first Page Resource. From a small unit that holds the same meaning on the Web and the console, you can start building an application that grows for the long term.
Quick start
VENDOR=MyVendor PACKAGE=MyProject \
composer create-project bear/skeleton my-project
cd my-project
php bin/page.php get /hello