Json Api Common Laravel Package

Product Decisions This Supports

• API contract standardization (build vs. buy). Supports the decision to adopt the JSON:API specification (jsonapi.org) rather than designing a bespoke REST contract, giving you a documented, tooling-friendly shape for resources, relationships, links, documents, and errors.
• Multi-client strategy. Informs whether to standardize responses so web, mobile, and partner integrations consume one predictable envelope (compound documents, sparse fieldsets, included relationships) instead of per-client DTOs.
• Feature/roadmap scoping. Helps size an "API conformance" workstream: attribute/meta conventions, relationship serialization, pagination and error objects can be specified up front rather than discovered mid-build.
• Shared client/server modeling. Relevant only if you plan to ship both a JSON:API server and client in PHP — the package's real purpose is to keep document/resource/error structures identical on both sides, reducing drift.
• Ecosystem investment. A signal for whether to lean into the enm family (json-api-server, json-api-client) versus a Laravel-native JSON:API implementation. This package alone delivers no endpoint behavior; it is a transitive building block.
• Integration/compatibility planning. Useful input when a customer, SDK, or front-end framework (e.g., Ember Data-style clients) already expects JSON:API semantics and you must decide whether to conform, translate at the edge, or decline.
• Risk and total-cost-of-ownership review. Its archived status, 2020 last release, low adoption (14 stars, 0 dependents), and dependence on sibling packages feed directly into maintenance-burden and exit-cost estimates.

When to Consider This Package

Consider it when:

• You are already committed to the enm JSON:API server/client stack and need the shared domain classes these two depend on — installing it directly is otherwise unnecessary, since it arrives as a dependency.
• You are working in an existing or legacy PHP codebase that already uses enm/json-api-server or enm/json-api-client and want consistent document, resource, link, and error structures across both.
• You need a lightweight, MIT-licensed set of POJOs/interfaces for JSON:API documents and want to avoid hand-rolling attribute, meta, link, relationship, and error models.
• You are evaluating the enm ecosystem and want to gauge whether its abstractions fit your domain model before adopting the server or client.
• Your team accepts vendor-pinning a frozen library for a bounded, non-critical surface where the structures are stable and you can fork or take over maintenance if needed.

Look elsewhere when:

• You are building greenfield on Laravel and want batteries-included routing, validation, pagination, and Eloquent integration — a maintained Laravel-native JSON:API package (e.g., the current laravel-json-api line) is the better fit; older cloudcreativity/laravel-json-api is itself legacy.
• You cannot accept an archived dependency: no security patches, no PHP 8.x/framework-version guarantees, and a 2020 release cadence means you inherit upgrade and CVE triage yourself.
• You need active support, community answers, or a contributor base — 14 stars and 0 dependents implies no meaningful ecosystem to lean on.
• You only need JSON:API-shaped output and not the client/server split — a single framework-native serializer/resource layer is simpler than adopting three coordinated packages.
• Your API style is GraphQL, gRPC, or plain REST with OpenAPI — JSON:API's compound-document model adds ceremony without matching payoff.

How to Pitch It (Stakeholders)

For executives: JSON:API is a mature, widely understood API standard, and adopting a standard reduces integration time, documentation effort, and client-specific rework — especially when several clients consume the same backend. However, this specific package is not the product decision: enm/json-api-common is a small, low-level shared library that only supplies document/resource/error structures, is archived, saw its last release in December 2020, and has negligible adoption. It is not a delivery mechanism on its own — it exists to be shared by the enm server and client packages. Recommendation: adopt the JSON:API specification, not this package. If we proceed with JSON:API on Laravel, we should select an actively maintained, framework-native implementation and treat enm/* as a fallback only if we inherit an existing codebase already on it.

For engineering: This provides the common vocabulary — traits, resources, relationships, attributes/meta, links, documents, and error/request abstractions — so a PHP client and server serialize identically and avoid contract drift. The API is documented (trait, resources, collections, links, documents, errors, requests) and MIT-licensed, so forking is legally straightforward. The costs are real: archived repo, stale Travis CI, no dependents, no guarantee of compatibility with current PHP or Laravel versions, and the burden of patching it ourselves. Sizing implication: adopting the enm trio means owning maintenance; adopting a maintained Laravel-native alternative means less control but far lower TCO. Decision asked of engineering: confirm whether any existing services already depend on the enm stack. If not, we standardize on JSON:API via a maintained implementation; if yes, we scope a contained fork-and-pin plan with an explicit exit path.