Jasper Rest Client Laravel Package

Product Decisions This Supports

• Embedding generated reports in a Laravel product surface. This package lets a PHP/Laravel application call a JasperReports Server (JRS) REST API to run reports and pull down outputs (PDF, XLSX, CSV, HTML), so it directly supports decisions like "do we ship customer-facing or internal reporting this quarter?" without building a report renderer.
• On-demand and scheduled report delivery for finance close packs, operations dashboards, compliance/audit exports, and invoice/statement generation — the classic JRS use cases.
• Build vs. buy on the reporting layer. It implies an architecture decision: buy/operate JasperReports Server as the report engine (authoring in Jaspersoft Studio, scheduling, multi-format export) and keep Laravel as the orchestration/auth/data layer. It is not a decision to build BI; JRS does the heavy lifting.
• Standardization / vendor-leverage decision. Choosing this package implicitly means committing to JRS. That should be weighed against Metabase, Superset, or a managed reporting API — and against simply using the upstream Jaspersoft/jrs-rest-php-client that this package copies.
• Roadmap sequencing for "reports" epics — spikes and estimates for a reporting feature can treat this client as a known-cost integration rather than greenfield work. Note the 2.0.0 major bump: if an estimate or spike was written against 1.x, re-baseline the dependency pin and PHP/Symfony constraints.
• Low strategic weight. With 0 stars, 0 dependents, and a self-described "copy … with small enhancements," this is a tactical integration artifact, not a platform bet. Product decisions it should not anchor: long-term API strategy, multi-tenant reporting SaaS, or anything requiring vendor support accountability.

When to Consider This Package

Adopt (or evaluate) when:

• You are already running JasperReports Server (or are contractually/technically committed to it) and need PHP-side integration to execute reports and fetch exports.
• Your app is PHP/Laravel, and the reporting engine is external — you want a thin client rather than hand-rolling REST calls and auth.
• You need a short, well-scoped integration (run report by URI, pass parameters, receive a file) and can absorb the wrapper yourself.
• Your runtime is compatible with the 2.0.0 dependency floor. Release 2.0.0 adds Symfony 7 support, which means the client rides on Symfony HTTP/related components. Confirm your PHP version and that this component set does not collide with your framework's HTTP stack (Laravel's HTTP client is Guzzle-based, so expect two HTTP layers unless you replace the transport).
• You have legal sign-off on LGPL-3.0 for your distribution model (internal use is typically fine; redistribution or modification triggers obligations that need review).

Look elsewhere when:

• You are not on JRS. Evaluate the engine first; the client choice is downstream of that.
• You need Laravel-native ergonomics (service provider, config publishing, facades, typed DTOs, Laravel HTTP client, queues). This remains a generic PHP REST client, not a Laravel package — the 2.0.0 "code quality" improvements do not add framework integration. Expect to write the glue yourself.
• You need maintenance confidence or community support. 2.0.0 is a mild positive signal — an outside contributor (@vinceAmstoutz) submitted a code-quality/encoding/Symfony 7 PR that was merged and shipped as a major — but one contribution is not a support commitment: still no SLA, no security disclosure process, no CVE monitoring, and no evidence of sustained triage. Prefer the upstream Jaspersoft/jrs-rest-php-client and carry your own patches, or fork deliberately into your own repo with a maintenance owner.
• You are mid-flight on 1.x. 2.0.0 is a semver-major: the Symfony 7 alignment can raise the PHP/component floor and is not guaranteed API-compatible. Read the diff against 1.0.0 before upgrading; the changelog line is terse and does not enumerate breaking changes.
• You are LGPL-averse for distributed/on-prem product builds and unwilling to do the compliance work.

Adoption gate (recommended): pin 2.0.0 (not a floating constraint), confirm the "small enhancements" against upstream, diff 1.0.0 → 2.0.0 to catch signature or dependency breaks, vendor the code into your repo with a named owner, and treat it as internal infrastructure — not an external dependency you rely on for upgrades. Add a regression test around the encoding fix (non-ASCII report names, parameters, and filenames) since that was the headline behavior change.

How to Pitch It (Stakeholders)

To executives: This is a small connector that lets our Laravel application ask an existing reporting server (JasperReports Server) to produce reports — PDFs, spreadsheets, scheduled statements — instead of us building report rendering ourselves. It's a thin, cheap piece of plumbing, not a platform decision. The strategic choice is whether we run JasperReports Server at all; if we do, this saves us a few weeks of integration work. The caveats are governance, not capability: the package is a lightly-modified copy of the vendor's own PHP client, has essentially no community adoption, and carries an LGPL-3.0 license that needs a quick legal check before we ship it to customers. The new 2.0.0 release is encouraging but small — an outside contributor fixed a text-encoding bug and added support for a newer PHP HTTP framework version, delivered as a major version bump we must pin and re-test. Recommendation: proceed with reporting-on-JRS only if we're already committed to that engine; otherwise evaluate alternatives first. If we proceed, use this as a reference implementation and own a small internal wrapper rather than depending on the fork.

To engineering: 2.0.0 is the same upstream Jaspersoft PHP REST client with minor changes plus one merged community PR (encoding fix, Symfony 7 support, general code-quality cleanup) — treat it as a starting point, not a dependency. It's a major version, so the Symfony 7 alignment likely moves the PHP/component floor; run the upgrade as a deliberate change with a full diff review, not a composer update. Vendor it, pin 2.0.0, and wrap it behind your own interface (a ReportService with typed inputs/outputs) so the client is replaceable. Note the extra HTTP layer: the client brings Symfony components while Laravel talks through Guzzle — keep the boundary explicit so you can swap the transport later. Still no Laravel service provider, no config, no tests worth relying on, and no guaranteed maintainer responsiveness. Budget for: authentication/session handling against JRS, parameter marshalling, streaming large exports, error mapping, queueing long-running reports, and a regression test for the non-ASCII encoding path that 2.0.0 fixed. LGPL means modifications to the library itself may carry obligations — keep our code in a separate layer and get legal to confirm the boundary before distribution.