Templated Uri Bundle Laravel Package

Product Decisions This Supports

• API contract & hypermedia strategy: Informs whether to expose RFC-6570 URI templates in API responses (HAL, Siren, JSON:API-style _links) so clients can discover parameterized endpoints — pagination, sorting, filtering, sparse fieldsets — instead of hard-coding URLs. This is a foundational decision for any product positioning itself as "API-first."
• API versioning and client-churn tradeoffs: Templated URLs let you add optional query params or path segments without shipping a new client SDK, reducing breaking-change pressure in roadmap debates. The PM decision is whether "evolvable API surface" is worth the template machinery.
• Build vs. buy triage: This package is a thin Symfony bundle wrapping hautelook/TemplatedUriRouter (essentially service registration plus a formatter). "Buy" is trivially cheap, but the bundle is archived. The realistic decision is build a ~50–100 LOC adapter over a maintained RFC-6570 library (Guzzle URI template, League URI, or rize/uri-template), or skip templating if native route generation suffices.
• Framework-fit decision: Critical flag — this is a Symfony bundle (AppKernel.php, Flex, hautelook.router.template service ID), not a Laravel package. For a Laravel product, it is a reference implementation only; the RFC-6570 concept transfers, the code does not. This shapes whether the team evaluates it at all.
• Supply-chain & governance posture: Adopting an archived, single-maintainer, 1-star, 0-dependent dependency is a policy question, not just a feature question — relevant for SOC2/regulated products, long-lived platforms, and any team that has committed to zero-abandonware policies.
• SDK/consumer tooling roadmap: If you generate SDKs or ship mobile/web clients, templated URIs give a stable, self-describing contract that eliminates per-client route duplication — a real input into roadmap prioritization for developer experience.
• Legacy modernization: If you are auditing eZ Systems / Symfony 3–4 era stacks, this bundle identifies an existing dependency needing replacement, feeding decommissioning planning.

When to Consider This Package

Consider it (as a reference, not a dependency) when:

• You are building on Symfony, not Laravel, and need route-aware RFC-6570 template generation from existing named routes.
• Your product requires hypermedia API discovery — clients must construct parameterized URLs for pagination, filters, or field selection from server-advertised templates.
• You are prototyping API discovery and want the fastest path to output like /demo?{&page}{&sort*}{&filter*} from $router->generate('route', ['page' => '{page}', 'sort' => ['{sort}']]).
• You need a worked reference of RFC-6570 semantics to train the team or to write spec documentation before building your own adapter.
• You are maintaining existing Symfony 3/4 code where the bundle is already installed and isolated.

Look elsewhere when:

• You are on Laravel. There is no first-party integration. You would consume the underlying router library directly, or better, a modern maintained URI-template library, wrapped in a Laravel service provider behind an application-owned TemplatedUriGenerator interface.
• Maintenance matters. Archived, 1 GitHub star, 0 dependents, README/CHANGELOG-only maturity, no security update path. This is effectively abandoned.
• You need current PHP/Symfony support. Constraints target pre-Flex Symfony; PHP 8.x and modern Symfony LTS compatibility is unverified. Forcing install with --ignore-platform-reqs is a red flag, not a workaround.
• Supply-chain review applies. Archived dependencies fail most governance gates; a fork transfers maintenance ownership to your team.
• You only need templating at the edges. A maintained RFC-6570 library plus a small framework adapter covers the need without the abandoned bundle.
• Placeholder validation, encoding of untrusted input, or caching of templates matters — these are unproven here and would need bespoke tests anyway.

How to Pitch It (Stakeholders)

Executive summary: This is a small, archived Symfony bundle that exposes an RFC-6570 URI-template router. The capability — server-advertised, parameterized URLs that let clients build API calls without hard-coded endpoints — is valuable for hypermedia-style APIs and reduces client churn when routes evolve. The package itself should not become a dependency: it is unmaintained, has essentially no adoption, and targets legacy Symfony, making it a poor fit for our Laravel/current-PHP stack. Recommendation: adopt the pattern, reject the dependency. Budget a small engineering task to implement a thin adapter over a maintained RFC-6570 library, and treat this repository as a design reference.

For engineering: The concept is a route-aware template generator: given a named route and parameters, emit RFC-6570-compliant templates for hypermedia payloads. Implementation surface is small. The plan: (1) confirm the product actually needs templates versus Laravel's native route()/url() generation, (2) pick a maintained RFC-6570 implementation (Guzzle URI template, League URI, rize/uri-template), (3) expose it behind an application-owned interface and service provider — never leak Symfony bundle conventions into Laravel, (4) add contract tests covering expansion, encoding, optional vs. missing variables, array parameters ({var*}), and caching, (5) roll out behind a feature flag with a documented exit path. Run a Composer dependency and license audit before any design work — including verifying what this package (ezsystems/templated-uri-bundle) actually is relative to the Hautelook upstream it documents, since provenance and canonical-package naming are inconsistent.

Key open questions to resolve before committing: Is templating required application-wide or only for a handful of external/API links? Do we need RFC-6570 specifically, or would conventional query strings with documented parameters suffice? Who owns the adapter long-term? And what is the fallback — maintained library, in-house expansion, or drop the feature — if compatibility fails?