Symfony Jsonrpc Http Server Doc Laravel Package

Product Decisions This Supports

• Build vs. buy for JSON-RPC API documentation: this package auto-generates HTTP JSON-RPC server documentation from Symfony route/controller metadata, so the "buy" decision saves the effort of hand-authoring and hand-maintaining a method catalog for an existing JSON-RPC surface.
• Developer-experience and partner-integration roadmap: a generated, always-current method reference is the artifact that unblocks external integrators, SDK authors, and internal consumers — treat it as a prerequisite for any "open our JSON-RPC API" milestone.
• Documentation-drift as a quality metric: because docs derive from the server definition rather than prose, it supports a decision to stop investing in manually maintained API wikis and instead track doc freshness as a release gate.
• Framework standardization decisions: the v2.0.2 change of the Composer type from library to symfony-bundle is a distribution-metadata signal, not a feature. It confirms this is a Symfony Flex bundle (installable/uninstallable via Flex, recipe-aware). For a PM this narrows the decision to "is our PHP surface Symfony or Laravel?" — and for a Laravel codebase the honest answer is that this is not a drop-in.
• Not a differentiator on its own: the release contains no functional change. Do not let it reset roadmap priority or trigger a migration project; it is version bookkeeping.

When to Consider This Package

Adopt when:

• The service exposing JSON-RPC is a Symfony application (Symfony Flex available); the new symfony-bundle Composer type presumes that ecosystem for discovery and enable/disable behavior.
• You have (or plan) a JSON-RPC 2.0 HTTP server whose method surface is worth publishing, and you want documentation generated from the server definition rather than written by hand.
• You need a low-effort, low-risk documentation layer — this is a thin, single-maintainer package, so it is cheap to trial on one service before committing.

Look elsewhere when:

• The stack is Laravel. There is no Laravel service provider, no Laravel auto-discovery, and the new Composer type actively reinforces the Symfony-only posture. Budget for a wrapper/adapter if you insist, or pick a JSON-RPC doc generator native to your framework.
• You need schema-first or OpenAPI/AsyncAPI output — generated Symfony route introspection is not a substitute for a spec-driven contract pipeline.
• You require vendor support, SLAs, or a large maintainer base. Assess bus-factor and issue-response history before making this load-bearing for external partners.
• The API is not JSON-RPC (REST/GraphQL) — the package's premise does not apply.

How to Pitch It (Stakeholders)

To executives: This is a small, free Symfony component that keeps our JSON-RPC API documentation automatically in sync with the code, closing a recurring source of partner-facing errors and support tickets. Cost is near zero; the value is faster external integration and less manual doc upkeep. The latest release (v2.0.2) is a packaging correction only — no new capability, no migration, no cost. I recommend a time-boxed pilot on a single Symfony service, with a caveat: it is Symfony-specific, so it is only relevant to our Symfony services, not our Laravel ones.

To engineering: v2.0.2 changes the Composer type to symfony-bundle (PR #36). Practical impact: Flex now treats it as a bundle for install/uninstall and recipe handling rather than a plain library. No code, API, or config changes; upgrade is a no-op beyond composer update. Two things to verify in the pilot: (1) confirm the bundle registers cleanly under our Flex configuration and that nothing in our deploy pipeline depends on the previous library type; (2) confirm generated output is committed or published as part of CI so docs cannot drift silently. Given single-maintainer risk, pin the version and keep the integration behind a thin seam so it can be swapped out.