Resource Index Link Laravel Package

Product Decisions This Supports

• API contract and data model design: v1.0.5 adds support for resource keys other than the standard id, which lets the team expose slugs, UUIDs, ULIDs, or external system identifiers in URLs and payloads without patching the package. This directly informs whether public identifiers are opaque (UUID/ULID) or human-readable (slug), a decision with security and SEO implications.
• Build vs. buy: The package now covers the common "custom route key" pattern out of the box. If the roadmap includes public-facing URLs with slugs or partner integrations keyed on external IDs, this reduces custom glue code and the maintenance burden of hand-rolling route model binding and resource resolution.
• Feature and roadmap sequencing: Custom-key support unlocks work that would otherwise be blocked — vanity URLs, multi-tenant scoping by external ID, and API versioning/migration where legacy IDs must persist alongside new ones. Worth slotting into the next planning cycle.
• Migration and backward compatibility: Teams can move from auto-increment id to a different key incrementally rather than a big-bang rewrite, lowering the risk of a data-model migration.
• Use cases: public REST/JSON APIs, partner-facing endpoints, content sites with slug-based routing, and any domain where the primary key should not be exposed.

When to Consider This Package

• Adopt when: you are building or refactoring APIs/resources where the identifier is not a plain id (slugs, UUIDs, ULIDs, external IDs); you want consistent route model binding and resource resolution across the app; or you are planning a migration away from auto-increment keys.
• Adopt cautiously when: your models rely entirely on standard id keys — the new capability adds no value and you should confirm the package still earns its dependency footprint.
• Look elsewhere when: you need deep, opinionated API standards (e.g., full JSON:API compliance), heavy performance tuning at very large scale, or you already have a mature in-house resource layer that this would duplicate.
• Evaluate before committing: this is a v1.0.x release; confirm test coverage, documentation of the new custom-key behavior (especially how it interacts with eager loading and authorization), and the maintainer's release cadence.

How to Pitch It (Stakeholders)

To executives: A small, targeted release closes a gap that would otherwise require custom engineering: the package can now address resources by keys other than id, such as slugs, UUIDs, or partner-facing external IDs. That directly supports cleaner public APIs, safer identifier exposure, and smoother data-model migrations — all without bespoke code we would have to build and maintain ourselves.

To engineering: v1.0.5 (contributed by @jeffreydevreede) adds support for non-standard resource keys. This means route model binding and resource resolution no longer assume id, so we can adopt UUIDs/ULIDs or slugs with the package's native behavior rather than writing adapters. Low-risk, additive change — but validate it against our authorization and eager-loading patterns and confirm the docs cover the new path before standardizing on it.