Client Laravel Package

Product Decisions This Supports

• Build vs. buy for service-to-service calls: sajya/client gives you a thin, Laravel-native JSON-RPC 2.0 client instead of hand-rolling HTTP wrappers, request/response envelopes, and error mapping — a decision worth revisiting any time we plan a new internal integration.
• Standardizing inter-service contracts: if our platform (or a partner) exposes JSON-RPC — particularly alongside sajya/server — adopting the paired client keeps both ends of the contract in one ecosystem and one release cadence.
• Roadmap sequencing for framework upgrades: release 1.5.0 widens the supported illuminate/http and illuminate/support version range. That is a signal the package tracks current Laravel releases, which de-risks scheduling our own Laravel upgrade without carrying a forked or abandoned dependency.
• Integration use cases to evaluate it against: internal microservice calls, calling third-party JSON-RPC APIs, and batch/notification style calls where a full REST or GraphQL layer would be over-engineering.
• Dependency-vetting decisions: 1.5.0 contains only CI cache bumps and a Laravel version-range update — no new features, no deprecations, no breaking changes. That means no migration budget, no regression test cycle beyond a standard CI run, and no reason to pin or defer.

When to Consider This Package

Adopt when:

• We already speak (or are about to speak) JSON-RPC 2.0 to a service, and especially when the server side is sajya/server.
• The consuming application is Laravel and we want the framework's HTTP client, config, and exception handling rather than a bespoke transport layer.
• We want a small, single-purpose dependency whose upgrade path is demonstrably maintained (as 1.5.0 shows).
• The team values a minimal surface area over batteries-included resilience features.

Look elsewhere when:

• The target API is REST, GraphQL, gRPC, or SOAP — this package is not a general HTTP client.
• We need out-of-the-box retries, circuit breakers, rate-limit backoff, or observability hooks; those would be our own layer on top.
• We need a generated, strongly typed SDK across many languages, or the consumer is not a Laravel/PHP application.
• The counterpart service does not actually implement JSON-RPC 2.0 — a spec mismatch here is a false economy.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk integration dependency, not a platform bet. The 1.5.0 release is pure maintenance — automated CI dependency bumps plus a widened Laravel version range — with zero breaking changes, zero new features, and no migration cost. Its practical value is that it keeps a supported, current-Laravel-compatible client available if we pursue JSON-RPC service integrations, and it signals the package is actively maintained rather than drifting.

To engineering: 1.5.0 updates illuminate/http and illuminate/support constraints (first contribution from @tabuna) and refreshes GitHub Actions cache versions. Nothing in our code changes. Action: run the normal dependency update and CI suite to confirm our Laravel version still resolves; treat this as a routine bump. If we standardize on JSON-RPC internally, this package is the default client choice alongside sajya/server; if the roadmap points to REST/GraphQL/gRPC, we should not adopt it at all.