Weave Code
Legacy Api Laravel Package
bagisto/legacy-api
A compatibility layer for Bagisto that restores legacy API endpoints and response behavior, helping existing integrations keep working after upgrades. Bridges older API clients with modern Bagisto while preserving expected routes and payloads.
At a glance
Frequently asked questions about Legacy Api
- What is bagisto/legacy-api used for?
- It is a compatibility shim for Bagisto that re-exposes pre-upgrade REST endpoints and response behavior for catalog, search, cart, checkout, customer accounts, orders, and invoices. It lets existing mobile apps and integrations keep working while the modern Bagisto API runs alongside it. It is intended as a strangler-style bridge during migration, not as a replacement for the current API.
- How do I install bagisto/legacy-api in a Laravel Bagisto application?
- Install it with Composer after confirming the 1.0.0 tag's dependency constraints match your Bagisto, Laravel, PHP, and JWT stack. The package uses standard Laravel package discovery and a service provider, and it ships a publishable config file. Publish and review that config for route prefixes, middleware, guards, and rate limiters before enabling endpoints, and register only the endpoints you actually need.
- Which Bagisto, Laravel, PHP, and JWT versions does bagisto/legacy-api support?
- There is no supported-version matrix baked into the package, and the only release is v1.0.0 from November 2021. You must read the composer.json constraints on that tag to determine which Bagisto, Laravel, PHP, and JWT versions it admits. If the bagisto/* constraint excludes your current major, treat the work as a fork project rather than a straightforward install.
- Is bagisto/legacy-api safe to run in production?
- Treat it as community-only and internally owned: it has one release from 2021, zero dependents, and no security policy. The biggest production risk is silent response drift, where a Bagisto upgrade changes a field name, cast, pagination envelope, null handling, or error code and breaks legacy clients without a deploy on your side. Run it as a time-boxed migration bridge with a named owner, contract tests, and a sunset date rather than as a permanent dependency.
- How does bagisto/legacy-api handle authentication and JWT tokens?
- Version 1.0.0 pulled JWT issuance, expiry, and revocation out of Bagisto core and into this package, which simplifies bootstrapping but concentrates auth risk in the shim. Configure a JWT secret and TTL for the legacy guard that are distinct from APP_KEY and from the primary API guard, and include that secret in your rotation plan. JWT divergence typically appears as blanket 401 responses that look like client bugs, and a missed rotation can take down the entire bridge.
- Will legacy API routes conflict with Bagisto's current API routes?
- Route shadowing is a real risk: a legacy prefix such as api can steal or lose routes depending on service-provider registration order and config cache state. The package is designed to coexist behind distinct route prefixes, middleware groups, and rate limiters, so verify those are separate from the modern API. Clear and rebuild the config cache after changes and audit the registered route list before deploying.
- Can bagisto/legacy-api help migrate mobile clients to the modern Bagisto API?
- Yes, that is its main structural fit: legacy and modern surfaces can run side by side behind separate prefixes, so you can retire legacy endpoints one at a time without touching the current API. Define which clients consume each legacy endpoint, skip endpoints with no consumer, and attach a client-migration plan to the sunset date. Without an executable migration plan, the bridge tends to become permanent.
- How should I test legacy API responses to catch silent drift?
- Create golden-response fixtures for every endpoint you expose and run them as contract tests against each Bagisto upgrade before it reaches production. Focus on pagination envelopes, null handling, error codes, and field names, since those are where legacy payloads derived from live core models and serializers tend to change quietly. The package has no upstream contract testing, so this artifact becomes your internal responsibility.
- What are the alternatives to bagisto/legacy-api?
- The main alternative is reproducing the old REST conventions in-house on top of current Bagisto services, which costs more glue code but gives you direct control over contracts and upgrades. Another option is to skip the bridge entirely and migrate clients straight to the modern API. Because the package is Laravel-native, its advantage is cheap integration, not reduced ownership.
- How do I configure route prefixes, middleware, and rate limits for the legacy API?
- Publish the package config and set a distinct route prefix, middleware group, and rate limiter for the legacy surface so it cannot overlap with the current API. Point the legacy guard at its own JWT secret and TTL, and document those values alongside your rotation procedure. Keep the config in version control and re-verify route registration after any Bagisto or Laravel upgrade.
Weaver
How can I help you explore Laravel packages today?