Api Validator Laravel Package

Product Decisions This Supports

• Contract-first / spec-driven API design. The library makes a Swagger 2.0 file executable: requests (headers, query, uri, body) and responses (headers, body) are checked against the published contract. This is the evidence needed to decide whether to standardize on spec-first workflows across teams.
• Build vs. buy (vs. adopt). Replaces hand-rolled FormRequest rules, custom middleware, and bespoke validators with a schema-driven approach. Useful for estimating the maintenance cost of validation code you would otherwise own.
• API governance and roadmap. Enables drift detection between documentation and implementation, which informs decisions on API versioning, deprecation policy, and whether to invest in a central API catalog or gateway.
• Placement decision: edge vs. in-app validation. Helps evaluate whether validation belongs in the application (this package) or at the API gateway/service mesh; the answer shapes platform architecture and staffing.
• Quality gates and CI. Response validation in staging or contract tests supports regression safety when refactoring endpoints and gives QA a machine-checkable definition of "correct."
• Use cases to prioritize: request-validation middleware for public/partner APIs, contract tests in CI, onboarding via living docs, and pre-release checks that examples in the spec actually match reality.

When to Consider This Package

Consider it when:

• You already maintain valid Swagger 2.0 descriptions (verified in Swagger Editor) and want them enforced at runtime rather than treated as documentation.
• You need both request and response validation from one schema.
• Your stack is PSR-7-compatible, or you accept adding a bridge (Laravel is not PSR-7 natively — expect a symfony/psr-http-message-bridge adapter and custom middleware/exception mapping).
• You want a small, dependency-light library (backed by justinrainbow/json-schema) over a heavier framework.
• You are willing to own a low-adoption OSS dependency: 24 stars, 0 dependents, readme-level maturity, Travis CI — i.e., no vendor support, no SLA, uncertain maintenance.

Look elsewhere when:

• Your specs are OpenAPI 3.0/3.1 — this package covers Swagger 2.0 only; prefer league/openapi-psr7-validator or cebe/php-openapi.
• You need guaranteed maintenance, security patching, or a roadmap commitment.
• You expect native Laravel ergonomics (validation rules, middleware, exception handling) out of the box.
• Validation is better handled at the API gateway or service mesh.
• You need RAML or API Blueprint today — those are stated future plans, not deliverables.

How to Pitch It (Stakeholders)

For executives: "We can make our API specification executable instead of aspirational. Adopting this library lets us validate live requests and responses against our published Swagger contract, reducing custom validation code and catching spec/implementation drift before customers do. Cost is low — one MIT-licensed dependency — but the project is small and lightly maintained, so I recommend a short proof of concept, isolating it behind our own validation interface, and keeping a migration path to a more actively maintained validator. Net: a cheap experiment with a bounded downside, not a platform bet."

For engineering: "It's a focused library that validates PSR-7 requests and responses against Swagger 2.0 using json-schema — fits as HTTP middleware and as a contract-test helper. Caveats: Swagger 2.0 only, no native Laravel integration (needs a PSR-7 bridge and our own middleware/exception handling), and the project shows low adoption and limited maintenance signal. Proposal: wrap it behind an internal ContractValidator interface, run a POC on one service, and benchmark against league/openapi-psr7-validator before committing. That gives us the option value without the lock-in."