Symfony Jsonrpc Http Server Openapi Doc Laravel Package

Product Decisions This Supports

• API contract strategy for JSON-RPC services. If the roadmap includes exposing internal JSON-RPC methods to other teams, partners, or generated clients, this package determines whether you can publish a machine-readable OpenAPI 3.0.0 spec without hand-maintaining docs. That is the core decision it informs: "do we invest in a contract-first workflow, or keep docs as a manual artifact?"
• Build vs. buy (vs. borrow) for documentation generation. The realistic comparison is not "buy a vendor" but "build a small internal generator" versus "adopt this bundle." This package is a concrete, MIT-licensed starting point that makes the build estimate smaller and the trade-off explicit.
• Framework fit check — and this is the important one. Despite the brief framing, this is a Symfony bundle, not a Laravel package. For a Laravel-first product org the honest decision it supports is "we do not adopt this; we either port the pattern or use a Laravel-native alternative." Treat it as a reference implementation and a signal about what the Symfony/JSON-RPC ecosystem offers, not as a drop-in dependency.
• Platform standardization. It supports a call on whether JSON-RPC + OpenAPI becomes a sanctioned internal integration pattern (SDK generation, gateway registration, contract tests) or stays a one-off per service.
• Adoption risk / vendor posture. With ~1 star, 0 dependents, and a single maintainer, the decision it most directly drives is "pilot, fork, or skip" — not "standardize."
• Roadmap sequencing. Useful for prioritising "publish a spec for our RPC surface" against other developer-experience work: the cost side of that initiative is now measurable rather than speculative.

When to Consider This Package

Consider it when:

• You are on Symfony and already using yoanm/symfony-jsonrpc-http-server — this bundle is purpose-built for that stack and offers little value in isolation.
• You need an OpenAPI 3.0.0 document generated from your existing JSON-RPC method definitions, typically to feed a gateway, client codegen, or contract tests.
• You want a low-commitment pilot: MIT license, small surface, no procurement cycle, and the code is readable enough to fork if the maintainer goes quiet.
• Your team is comfortable owning a dependency with near-zero community gravity — no Stack Overflow corpus, no third-party tutorials, no ecosystem of examples.

Look elsewhere when:

• You are on Laravel. There is no Laravel integration here, and the JSON-RPC server bundle it documents is Symfony-specific. Budget for a rewrite of the pattern, not an install.
• You need OpenAPI 3.1, JSON Schema 2020-12 semantics, or spec features beyond what a 3.0.0 generator emits.
• You need vendor support, SLAs, or a security review trail — a single-maintainer project with 0 dependents will not clear most enterprise dependency gates without a fork-and-own plan.
• Your API is REST/gRPC-first; JSON-RPC-to-OpenAPI mapping is inherently lossy and you will spend more time explaining the translation than writing docs.
• You require proven production track record. One star and zero dependents means you are the reference implementation.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed open-source component that would let us auto-generate API documentation from code instead of writing it by hand — reducing doc drift and unblocking client SDK generation for our RPC services. The financial risk is effectively zero; the strategic risk is concentration: it is maintained by one person with essentially no public adoption, so we should treat it as a pilot or a fork candidate, not a platform commitment. Recommended ask: a short engineering spike, not a roadmap line item. Also flag the framework mismatch up front — it targets Symfony, so if our services are Laravel the realistic outcome is "borrow the approach," and the spike should be scoped to that.

To engineering: It is a Symfony bundle that emits an OpenAPI 3.0.0 document for a yoanm/symfony-jsonrpc-http-server service. If we are on that stack, it removes hand-written spec maintenance and gives us a contract artifact we can wire into CI (spec diffing), gateway registration, and client generation. If we are on Laravel — which we are — the value is as a reference implementation: the mapping strategy from JSON-RPC methods to OpenAPI paths and schemas is the reusable asset, and it is small enough to read in an afternoon and reimplement in a Laravel service provider. Either way, plan to own it: pin the version, vendor or fork the source, and do not expect upstream fixes on our timeline. Success criteria for the spike: a generated spec that (a) validates against OpenAPI 3.0.0, (b) round-trips through our gateway or a codegen tool, and (c) stays in sync with route changes without manual edits.