Json Api Client Laravel Package

Product Decisions This Supports

• Build-vs-buy for consuming a JSON:API service. If your Laravel product needs to integrate with an existing JSON:API backend (Drupal JSON:API, Ember-facing APIs, SaaS partners, or an internal service standardized on jsonapi.org), this package is a reference implementation of the client side: typed request/response objects, include, sparse fieldsets, pagination links, and relationship handling. It lets you estimate integration effort before committing to a bespoke client.
• API standard decision (server side). This is the client half of the enm family (enm/json-api-common, enm/json-api-server). Choosing JSON:API as your public contract implies needing a client like this for PHP consumers. That informs whether to standardize internal APIs on JSON:API at all versus simpler REST/GraphQL.
• Roadmap scoping for integrations. The package shows the shape of the work: PSR-18 HTTP client wiring, URI/request/stream factories, serializer/deserializer, and resource/relationship document models. That is a concrete backlog item rather than a vague "add API client" epic.
• Third-party dependency risk register. Archived status + last release 2019-08-29 + 18 stars + 0 dependents is a clear signal: any adoption is effectively a fork-and-own decision, which should be recorded as technical debt and budgeted for.
• Use-case fit: best for read-heavy integrations against a compliant JSON:API server; less suitable where the API deviates from spec or where you only need one or two endpoints (a thin custom client wins).

When to Consider This Package

Consider it when:

• You are building a PHP/Laravel client (not server) against a genuinely JSON:API-compliant endpoint.
• You want the document model (resources, relationships, links, errors) handled for you rather than hand-rolling arrays.
• You are comfortable with PSR-18 and can supply an adapter (e.g., Guzzle via a PSR-18 adapter, Symfony HTTP Client) plus PSR-17 factories (nyholm/psr7).
• You are willing to vendor/fork and accept maintenance ownership, or you only need it as a reference implementation to copy patterns from.
• Your PHP/runtime constraints are compatible with a 2019-era codebase (PHP 7.x lineage), and you can validate PHP 8.x compatibility yourself.

Look elsewhere when:

• You need active maintenance, security patching, or community support — this repo is archived and unmaintained.
• You want a Laravel-native experience (service provider, config publishing, facades, HTTP client macros). There is none here; you wire it manually in the container.
• You need a server implementation of JSON:API in Laravel (look at laravel-json-api/cloudcreativity lineage, or enm/json-api-server with the same caveats).
• You want a maintained, higher-level HTTP abstraction for integrations — e.g., Saloon with a JSON:API plugin, or a thin typed client over Laravel's Http facade, gives you more longevity.
• Your API is non-compliant or custom, in which case the spec abstractions add friction rather than value.

How to Pitch It (Stakeholders)

Executive summary: enm/json-api-client is a small MIT-licensed PHP library that implements the client side of the JSON:API specification. It provides structured request builders and response deserialization (resources, relationships, includes, pagination, errors) on top of any PSR-18 HTTP client, so a Laravel app can talk to a JSON:API backend with less bespoke parsing code.

The honest caveat: it is archived, last released in August 2019, with 18 stars and zero known dependents. It is not a live dependency; it is a starting point or reference. Adopting it means forking it, validating it on current PHP/Laravel, and owning it.

Recommendation for engineering: use it to accelerate the first integration or to copy its document-model design, but do not treat it as a supported upstream. Budget a small fork-maintenance line item. If the integration is small, a thin typed client built directly on Laravel's HTTP client will likely cost less over 12 months than owning a fork.

Recommendation for product: it does not change what you can build — it shortens the path to consuming JSON:API services and clarifies the cost of choosing JSON:API as a contract. Treat it as an enabler for integration scope, not as a strategic dependency.