Wp Rest Laravel Package

Product Decisions This Supports

• Choosing an attribute-driven, auto-discovered REST controller pattern over manual register_rest_route() calls for WordPress products built on the Pollora stack.
• Standardizing API surface across plugins and themes: controllers are resolved with constructor dependencies, so teams can keep REST logic in dedicated classes and inject services via PSR-11.
• Build-vs-buy: use the extracted package rather than maintaining a private copy of src/WpRest; the package carries history and an architecture test that limits scope to attributes, discovery, PSR contracts, and WordPress.
• Roadmap sequencing: treat v0.1.0 as a foundation for the framework’s next release, with 1.0.0 targeted to that release; plan adoption behind the framework upgrade rather than as an independent 1.0 dependency.
• Reuse beyond full Laravel: because it runs without Laravel’s application, it can support lightweight WordPress REST endpoints in contexts where only a PSR-11 container is available.
• Migration planning: class names and namespaces remain Pollora\WpRest\* and Pollora\Support\WpGlobals, so existing code extracted from the framework should port with limited namespace churn.

When to Consider This Package

Consider it when:

• You are building or maintaining WordPress REST endpoints on PHP 8+ and want attribute-based route declaration with discovery.
• Your product is on, or about to adopt, the Pollora framework’s next release and can align with its 1.0.0 timeline.
• You can supply a PSR-11 container and want constructor dependency injection in REST controllers, including custom HandlesAttributes attributes.
• You value a narrow, test-enforced architecture: attributes, discovery, PSR contracts, and WordPress only.
• You are comfortable with pre-1.0 API churn and can pilot rather than standardize immediately.

Look elsewhere when:

• You need a stable 1.0 contract now, or cannot wait for the framework release that 1.0.0 tracks.
• You need Laravel-specific integrations beyond PSR-11, or you are not on WordPress.
• You cannot adopt Pollora namespaces (Pollora\WpRest, Pollora\Support\WpGlobals) or need a vendor-neutral namespace from day one.
• You require mature documentation, long-term support commitments, or a broad plugin ecosystem; v0.1.0 is a first extraction, not a mature standalone product.
• Your REST layer is simple enough that manual registration is cheaper than adding discovery and container plumbing.

How to Pitch It (Stakeholders)

Executives: This package gives our WordPress products a consistent, testable way to expose REST APIs, reducing bespoke route wiring and making controller code easier to maintain. It is a first release extracted from our framework, not a mature 1.0 dependency; the recommendation is a limited pilot tied to the framework’s next release, with broader adoption gated on 1.0.0. The upside is lower maintenance and reuse outside full Laravel; the risk is pre-1.0 API change and dependence on Pollora conventions.

Engineering: v0.1.0 extracts src/WpRest with its history intact. Controllers are discovered and built by an instance resolver with constructor dependencies; custom HandlesAttributes attributes receive the PSR-11 container passed to WpRestDiscovery. It does not require Laravel’s application, and an architecture test constrains the package to attributes, discovery, PSR contracts, and WordPress. That makes it easy to reason about and test, but also means no Laravel-specific magic. Class names remain Pollora\WpRest\* and Pollora\Support\WpGlobals, so migration from framework code should be mostly namespace and package wiring. Expect API stabilization at 1.0.0; pin v0.1.x, pilot one endpoint set, and track the framework release before committing multiple teams.