Templated Uri Router Laravel Package

Product Decisions This Supports

• Hypermedia API strategy (HATEOAS / HAL / JSON:API / Siren). The core capability — emitting RFC 6570 URI templates rather than fully-expanded URLs — is what lets an API response say "search": "/orders{?status,page,limit}" instead of hard-coding one link per filter combination. This is a product/API-design decision about discoverability, not just a routing detail.
• API discovery documents and root resources. A single templated route can describe the entire affordance surface (filters, sorting, pagination, sparse fieldsets) without inventing a bespoke metadata format. That reduces the "read the docs to know what's queryable" tax on integrators.
• Endpoint surface / combinatorial explosion. If your roadmap includes letting clients compose filters and pagination, URI templates let you ship one route plus a template instead of N documented variants — a direct reduction in surface area to test, version, and support.
• SDK and client generation. A machine-readable template set is a build-time input for generated clients, so "which URLs can I call and how" becomes a generated artifact rather than hand-maintained documentation that drifts.
• Webhook and callback URL design. Templated callbacks (with tenant, resource, and signature placeholders) are a recurring integration requirement across billing, notifications, and eventing — worth deciding once, at the platform layer.
• Build vs. buy vs. borrow. The real decision this package forces is not "adopt or not" but "do we take the RFC 6570 capability from an unmaintained Symfony bundle, compose it from a small template library, or own ~150 lines of adapter over our own route collection."
• API versioning and deprecation. Templates give you a place to express optionality ({?expand}) without a v2, which is usually cheaper than a version bump.

When to Consider This Package

Consider it when:

• You are already on Symfony and want templated URIs emitted directly from your existing route definitions — that is exactly the integration seam this package occupies, and it is where it earns its keep.
• You are committed to a hypermedia-driven API and need server-side generation of Level 1–4 RFC 6570 templates from route metadata, rather than hand-writing template strings.
• You are comfortable treating it as a reference implementation to read and vendor (MIT license permits this) rather than a dependency you expect to track upstream.

Look elsewhere — or plan to build — when:

• You are Laravel-first. This is Symfony Routing–coupled; adopting it means running Symfony's routing component alongside Laravel's router, which is real integration friction for a narrow gain. Use guzzlehttp/uri-template or rize/uri-template directly and write a thin adapter over Route::getRoutes(). That is a day of work and gives you a dependency you can reason about.
• You need maintenance guarantees. Two stars, zero dependents, and a last release in January 2023 is a clear signal: no meaningful user base, no downstream pressure to keep it compatible with current Symfony/Laravel versions. Score and opportunity metrics agree.
• Provenance matters to your supply chain review. The listed package name (hautelook/templated-uri-router) and the repository (goetas/TemplatedUriRouter) do not match — this is a fork. Confirm which artifact you would actually install, who publishes it, and whether the fork or the original is the maintained one. Two similar low-activity repos is a fork-drift risk.
• Hypermedia is aspirational, not committed. If no client will consume templates, you are paying an abstraction cost for a spec nobody reads. Ordinary route() output is fine.
• You need first-class docs, examples, and community answers. You will be reading the RFC and the source, not Stack Overflow.

How to Pitch It (Stakeholders)

To executives (one paragraph): There is a spec — RFC 6570 — for describing URLs with fill-in-the-blank placeholders, and it is how modern hypermedia APIs tell clients what they can ask for without a page of docs per endpoint. This package implements that for Symfony. It is a capability, not a platform: tiny user base, no releases since early 2023, no downstream dependents. The recommendation is to treat it as a design reference and either adopt it only if we are on Symfony, or spend roughly one engineer-day building the equivalent adapter on top of a maintained URI-template library. Either way the strategic value is the same — fewer hand-maintained endpoint variants and a machine-readable contract for generated clients — and the cost of the "build" path is low enough that maintenance risk should not be the deciding factor.

To engineering (bullets):

• The value is RFC 6570 Level 1–4 template generation from route definitions, not the bundle wiring.
• Symfony Routing integration is the differentiator and also the blocker for us if we are on Laravel — budget a small adapter over Laravel's route collection instead of importing Symfony's router.
• MIT licensed, so vendoring or forking is permitted; pin a commit and document it if we depend on it at all.
• Keep the template-emission concern behind our own interface so we can swap the underlying library without touching controllers or serializers.
• Confirm artifact identity before install (fork vs. upstream) and add it to the dependency-review list given the release gap.