Jsonrpc Server Doc Sdk Laravel Package

Product Decisions This Supports

• API documentation as a shippable feature, not a side project. If we expose a JSON-RPC 2.0 server (internal platform API, partner integration, mobile backend), consumer-facing docs are part of the product surface. This SDK gives us a repeatable generator instead of hand-written Markdown that drifts from the contract.
• Build vs. buy for doc tooling. The realistic comparison is: (a) hand-maintained docs, (b) an internal generator, (c) this MIT-licensed SDK. For a small team, (c) is the cheapest starting point — but only if we accept owning the integration and any gaps.
• Protocol/architecture choice. Laravel's ecosystem is REST-first; JSON-RPC is a deliberate architectural bet. Investing in JSON-RPC docs signals commitment to that bet. If we are still undecided between JSON-RPC, REST, and GraphQL, this package is premature — our doc tooling should follow the protocol decision, not drive it.
• Developer-experience roadmap. Good generated docs reduce integrator time-to-first-call, support tickets, and back-and-forth in partner onboarding. This is a measurable DX lever (onboarding time, ticket volume per integration) rather than a purely technical artifact.
• Foundation for downstream artifacts. A machine-readable method/parameter catalog is a prerequisite for client SDK generation, contract tests, and API governance/changelog processes. Even if the rendered HTML is only adequate, the structured definitions may be the more valuable output.
• Vendor/risk decision. Stars (0), dependents (0), and a single-maintainer profile mean this is an evaluate-and-vendor candidate, not a standardize-the-company-on-it candidate. The decision this supports is "spike it behind an internal adapter," not "make it a platform dependency."

When to Consider This Package

Consider it when all of the following hold:

• We already run, or have firmly committed to, an HTTP JSON-RPC server in PHP, and the server surface is large enough (roughly 10+ methods) that manual docs are a real maintenance burden.
• We have multiple consumers — external partners, several internal teams, or generated clients — for whom an accurate method/parameter reference is a product requirement.
• We can pin a version, vendor the source, and assign an internal owner. With zero dependents, we are effectively the first production user; assume we will find and fix issues ourselves.
• We are willing to wire it into Laravel ourselves (service provider, Artisan command, CI step). This is framework-agnostic PHP with no Laravel package, config publishing, or Blade integration out of the box.
• We have verified the critical diligence question: does it derive definitions from our actual server code, or from a separately maintained doc config? If the latter, we are trading one dual-maintenance problem for another, and the ROI case weakens considerably.

Look elsewhere when:

• Our API is REST/OpenAPI — use Scribe or Scramble; this package does not model REST.
• We need a Laravel-native, batteries-included experience (auto-discovery of routes, auth examples, Postman/OpenAPI export, hosted UI).
• We need commercial support, SLAs, or an active community — none exist here.
• The API is GraphQL or gRPC, or JSON-RPC over WebSockets/non-HTTP transports.
• Docs are a one-off deliverable for a small, stable API — a hand-written reference plus JSON Schema will be cheaper than an integration.
• We cannot absorb the maintenance risk; a stale doc generator is worse than no generator because it silently publishes wrong contracts.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed tool that automates reference documentation for our JSON-RPC API, replacing hand-maintained docs that go stale and generate support load. Cost is near zero in license terms; the real investment is a short engineering spike plus an internal owner. Because the project has no meaningful adoption yet, I recommend a timeboxed evaluation (one engineer, 1–2 sprints) with a documented exit path, not a platform commitment. Success criteria: docs generated from a single source of truth, published in CI, and a measurable drop in integrator questions.

To engineering: It is a PHP SDK that renders JSON-RPC server documentation from method/parameter definitions, framework-agnostic — so in Laravel we add a service provider and an Artisan command, and run it in CI to catch contract drift. Two caveats to validate in the spike: (1) whether definitions are introspected from our code or declared separately, and (2) the output format's fitness for a developer portal. Pin the version and vendor it; we are early adopters here.

Recommendation: Spike, don't standardize. Adopt behind a thin internal interface so we can swap in a hand-rolled generator or another tool without touching product code. Revisit the decision after the spike, weighing generated-doc quality against the ongoing cost of ownership.