Templated Uri Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for dynamic URL generation. If a feature needs to hand back URL-shaped contracts rather than finished links — e.g. /products?{&filter*}{&sort}{&page} — this package buys that capability instead of us writing and maintaining RFC-6570 expansion logic plus a Symfony integration. That is a genuine "buy" saving on a small but fiddly and spec-driven piece of code (reserved-character encoding, prefix/explode modifiers, brace escaping are exactly where hand-rolled implementations break).

• Roadmap input for hypermedia / discoverable APIs. The package's real value is in HATEOAS-style responses and API discoverability: instead of the server guessing every link variant, it returns a template the client completes. That is a roadmap-level decision (do we ship self-describing APIs?) more than a library decision, and this package is the cheapest way to prototype an answer.

• Feature scoping for filtering, sorting, pagination, and faceted search. Any place we currently emit N hardcoded link permutations (page sizes × sort orders × filters × facets), a URL template collapses N to 1. This is disproportionately valuable for search/listing UIs and for partner integrations that consume our links.

• Standardisation decision. RFC-6570 is mature and tooling exists in most client languages. Deciding to expose templates rather than bespoke query-string conventions is a small, low-cost standards bet we can reverse cheaply.

• ⚠️ Framework-fit decision, which for us is the blocking one. Despite being listed as a "Laravel/PHP package," this is a Symfony bundle that registers hautelook.router.template in the Symfony DI container. It is not usable as-is in Laravel. So the first PM decision it supports is a stack check: if our product is Laravel-first, this is a reference implementation to copy ideas from, not a dependency. On Laravel we would either build the small expansion layer ourselves or use a standalone URI-template library, and wire it through Laravel's URL generator.

• Vendor-risk posture. 3 stars, 0 dependents, a single-vendor fork (Ibexa maintains it for its own DXP), readme/changelog-only maturity. That is fine for an internal utility with a clear owner; it is a poor foundation for anything customer-facing and load-bearing. This package's best use is as a low-cost spike, not a platform bet.

When to Consider This Package

Adopt (or spike) when:

• The codebase is Symfony (this fork's 6.0.0 line adds PHP service config and Symfony 8 support, so it is at least maintained in step with current Symfony).
• You have a concrete, identified need for RFC-6570 templates — HATEOAS links, discoverable APIs, or combinatorial query-parameter links — rather than a vague "nice to have."
• The templated router can run alongside the native Symfony router on selected routes; this is additive, so blast radius is small and a pilot is genuinely reversible in a day or two.
• You accept owning the risk: pin versions, add our own tests around the expansion paths we actually use, and treat the service as an internal detail behind our own abstraction so we can swap it.
• You want to evaluate the pattern cheaply before committing to it in an API contract.

Look elsewhere when:

• You are on Laravel. This is the decisive criterion. Non-Symfony stacks get no value from the bundle; only the underlying URI-template concept transfers.
• Your routes are largely static (/orders/{id}) and Symfony's native router already covers them. Adding a second router for no templated use case is pure overhead.
• You need URI templates outside URLs — headers, request bodies, message payloads — or need full spec coverage including exotic operators not exercised by this bundle.
• You require commercial support, security response guarantees, or a broad contributor base. Three stars and zero dependents means we are effectively the maintainer.
• Your platform has strict dependency-review gates that block low-adoption, single-vendor forks — worth checking before anyone spends a sprint on it.
• You would rather not add a second routing abstraction at all; for a single endpoint you can format a template string by hand and skip the dependency.

How to Pitch It (Stakeholders)

To executives (one paragraph): "There is a small, MIT-licensed library that lets a Symfony API return link templates — /reports?{&from}{&to}{&group} — instead of a fixed set of hardcoded links. The business value is fewer bespoke endpoints and integrations that keep working as we add filters, without us shipping a new link format each time. Cost is low: the pattern is a published standard (RFC-6570), integration is additive to our existing router, and a pilot is roughly a day or two of engineering. The caution is equally clear: it is a niche package from a single vendor with almost no adoption, so I'd fund it as a timeboxed pilot inside one API, not a platform standard — and if our product is Laravel-based rather than Symfony-based, the answer is no on this package and we take the idea, not the code."

To engineering leads: "RFC-6570 templated URI bundle for Symfony; fork of hautelook/templated-uri-bundle, maintained by Ibexa. It exposes a hautelook.router.template service that generates templates like /demo?{&page}{&sort*}{&filter*}, and it augments rather than replaces the native router — existing routes are untouched. Known tradeoffs: minimal test coverage historically, single-vendor maintenance, and it's Symfony-only so it's a non-starter for Laravel services. My ask: one sprint spike on a single read-only listing endpoint, our own tests around the operators we use, the templated service hidden behind our own interface so the dependency is swappable, and a written go/no-go against three questions — does it reduce link permutations we actually ship, can clients consume templates, and are we comfortable owning the code if upstream stalls?"

Rollout, if approved: pilot on one non-critical endpoint → confirm client consumption story → adopt behind an internal abstraction for HATEOAS/listing endpoints → explicitly decline broad adoption. Alternatives considered: Symfony's native router (no template support), a one-off string formatter for a single endpoint (cheapest if the need is narrow), or a standalone URI-template library wired through our own URL generator (best fit if the stack is Laravel).