Json Api Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for JSON:API integrations. If a roadmap item depends on consuming a JSON:API–compliant backend (Drupal, Ember Data, many headless CMS APIs), this package is a candidate to avoid writing a bespoke serialization/deserialization layer. However, given the archived status, the realistic "buy" decision is to evaluate maintained alternatives (e.g., swisnl/json-api-client, Symfony HttpClient + a typed DTO mapper) rather than adopt this specific bundle.
• API contract standardization. Choosing JSON:API as an internal/external contract is a product-architecture decision; this bundle represents the Symfony-side integration cost of that choice. Use it to estimate effort when the org debates "JSON:API vs. plain REST vs. GraphQL."
• Time-boxed prototyping / spike work. The configuration surface is minimal (register bundle in bundles.php, one YAML block with named clients, private DI services enm.json_api_client.YOUR_CLIENT_NAME). That makes it a low-effort way to validate JSON:API feasibility before committing to a vendor or platform.
• Vendor/platform selection. If a vendor exposes a JSON:API endpoint and the team runs Symfony, this informs "can we integrate in days?" — but the archived repo should push the decision toward building a thin in-house client or adopting a maintained lib.
• Not a differentiator. At 0 stars, 0 dependents, and readme-only maturity, this is not a strategic dependency. It should never appear on a "platform investments" roadmap as a foundation.

When to Consider This Package

Consider (briefly, with caveats) when:

• You have a Symfony application and a JSON:API–compliant backend already in place, and you need a zero-friction proof of concept.
• You want a PSR-18-based HTTP integration (recommended: kriswallsmith/buzz + nyholm/psr7) so the transport layer is swappable.
• You recognize the value is only the thin Symfony wiring (bundle registration + named clients as private DI services), which is easy to replicate or fork.
• You can afford to pin, vet, and monitor an archived dependency, or you're evaluating it purely as reference code.

Look elsewhere when:

• Maintenance matters. The repository is archived; no security patches, no PHP/Symfony version compatibility updates, no issue triage. In a production roadmap this is a red flag.
• Supply-chain or compliance review is required — archived, 0 dependents, readme-only documentation will fail most dependency governance checks.
• You need richer features (pagination helpers, relationship traversal, error-object handling, OpenAPI-like tooling) — evaluate swisnl/json-api-client or a maintained equivalent.
• Your stack isn't Symfony, or you'd rather use Symfony HttpClient directly with a serializer/DTO mapping layer for full control.
• You need documentation, community support, or SLAs — none of which this offers.

How to Pitch It (Stakeholders)

To executives (in one paragraph): We found a small, MIT-licensed Symfony helper for talking to JSON:API backends. It could shorten a prototype by a few days, but the project is archived, has no users, and no maintainers, so it is a tactical, throwaway tool — not a strategic dependency. Recommendation: use it (or its patterns) only for a time-boxed spike; for anything on the roadmap beyond a demo, budget for a maintained library or a small in-house client so we avoid carrying an unmaintained dependency into production.

To engineering:

• It's a thin bundle: registers EnmJsonApiClientBundle, reads a YAML clients map, and exposes each client as a private DI service (enm.json_api_client.<name>), so it's injectable but not service-locator-accessible.
• Transport is PSR-18, so we can swap HTTP clients (buzz + nyholm/psr7 recommended) without touching calling code.
• Because it's archived and readme-only, treat it as reference implementation: we can either fork it (small surface, low fork cost) or port the wiring into an in-house bundle. Either way, plan an exit strategy before any production use.
• Action: run a 1–2 day spike against our actual JSON:API endpoint; if the DX holds, fork + pin and add a Symfony/PHP version matrix to CI; otherwise, adopt a maintained alternative.