Jsonrpc Params Symfony Validator Sdk Laravel Package

Product Decisions This Supports

• Feature scoping for any JSON-RPC surface. If the roadmap includes a JSON-RPC 2.0 API (partner integrations, internal service-to-service calls, batch endpoints), params validation is the gate on every request. This package is the piece that decides how invalid params become a spec-compliant -32602 Invalid params error with structured data — a decision that gets locked in early and is expensive to reshape later.
• Build vs. buy, narrowly framed. This is not a platform decision — it's a ~1-class adapter that binds Symfony's Validator to the yoanm params-validator interface. The real buy decision is "adopt the yoanm JSON-RPC SDK stack"; this package is a downstream consequence of that. Treat it as a line item, not a strategic bet.
• Validation-vocabulary standardization. Choosing this means the team writes Assert\Type, Assert\NotBlank, Assert\Valid, and custom constraints for RPC params, while Laravel's Illuminate\Validation rules handle HTTP form/API validation. That's two validation dialects in one codebase — a real maintainability cost that should be an explicit, documented decision rather than an accident.
• Use cases it genuinely serves: nested/polymorphic params (single object vs. array for batch), per-method constraint groups, localized violation messages, and reuse of existing Symfony constraint libraries. It does not address auth, rate limiting, transport, or schema documentation — don't let it absorb scope in planning.
• Roadmap signal, not a commitment. With 1 star, 0 dependents, and a single maintainer, adoption is a bet on an unproven dependency. It supports a "de-risk with a timeboxed spike" decision far better than a "standardize on this" decision.

When to Consider This Package

Adopt if:

• You are already committed to yoanm/php-jsonrpc-server-sdk (or equivalent) and need a params validator that satisfies its interface without hand-rolling one.
• Your team has existing Symfony Validator constraint classes worth reusing, or you need nested object validation with groups and translated messages — cases where Laravel's rules get awkward.
• You want validation kept out of controllers/handlers and expressed as declarative metadata.
• You're comfortable owning a fork: MIT license, tiny surface, but bus factor of one.

Look elsewhere if:

• You're a Laravel-first shop. Illuminate\Validation already covers 90% of this; a ~50-line adapter implementing the same interface avoids introducing a second validation paradigm and a Symfony service-container bootstrap inside Laravel.
• You aren't on the yoanm SDK. The value is entirely in conforming to its interface — outside that stack it's near-useless.
• You need schema-driven contracts (OpenAPI/JSON Schema) rather than code-level constraints — reach for opis/json-schema or justinrainbow/json-schema.
• You need high-throughput validation. Constraint metadata loading is cacheable but not free; benchmark before committing to a hot path.
• You require vendor stability guarantees. Zero dependents means zero field validation of this package — you are the field test.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed adapter that lets us validate JSON-RPC request parameters using a mature, widely-used validation library instead of custom code — less bespoke logic, fewer validation bugs, faster delivery on any RPC-facing feature. Cost is near zero; the risk is maintenance (one maintainer, negligible adoption), mitigated by the tiny surface area and the fact that swapping in our own adapter is roughly a day of work. Recommendation: approve as a timeboxed spike inside an existing initiative, not as a standalone standards decision.

To engineering: It's a thin bridge between the yoanm JSON-RPC SDK's params-validator interface and Symfony Validator — you get declarative constraints, nested validation, groups, and i18n violation messages for free. Be clear-eyed on three things: (1) it's Symfony-flavored inside a Laravel app, so we own bootstrapping the Validator, translation, and mapping ConstraintViolationList into JSON-RPC error data; (2) it introduces a second validation dialect alongside Illuminate\Validation — a deliberate trade, not an oversight; (3) we should assume we may need to fork it, so keep our usage confined to the interface boundary and cover it with contract tests. Default position: build the adapter ourselves unless we've already standardized on the yoanm SDK stack.