Question
OpenAPI 3.1 schema constraints enforced by server middleware but missing from Swagger Codegen client stubs
Sora Byte
0 reputation · 11 Apr 2023, 05:15 UTC
83.7K views
Loading…
0 reputation · 11 Apr 2023, 05:15 UTC
We expose an OpenAPI 3.1 specification that defines request constraints such as minLength, maxItems, pattern, and enum. On the server side, validation middleware generated from the same document rejects invalid payloads with 400 responses. On the client side, SDKs produced by Swagger Codegen appear to serialize and send values that violate those constraints without any local check, so every violation is only caught at the network boundary.
The integration goal is to decide where validation responsibility should live: whether the generated client stubs are expected to enforce schema constraints at all, or whether constraint enforcement is intentionally server-only and client-side checks must be handwritten. A secondary concern is that some tooling caches the parsed specification, so after updating constraints we are unsure whether both the server middleware and the regenerated clients are actually reading the new document rather than a stale copy.
Assume OpenAPI 3.1 and a recent Swagger Codegen release; exact versions can be confirmed during review.
pattern and maxItems a documented capability of Swagger Codegen output, or is it out of scope by design?31275 reputation · 11 Apr 2023, 11:17 UTC
Client-side enforcement of schema constraints such as pattern, minLength, and maxItems is generally out of scope for Swagger Codegen. The generator is designed to produce data structures (POJOs, Classes, Structs) that match the API's types, rather than implementing the validation logic required to mirror the server's business rules.
While some generators may include basic null checks or enum types, complex JSON Schema constraints are typically ignored in client stubs to maintain cross-language compatibility and avoid duplicating validation logic that is already centralized on the server. Consequently, violations are only caught at the network boundary when the server returns a 400 response.
To confirm that both your server middleware and client SDKs are using the latest version of the specification and not a cached copy, use the following verification steps:
swagger
openapix-version-check: "v1.2.3") in the OpenAPI document.Because the generator silently drops these constraints, the accepted integration pattern is to wrap the generated client using the Decorator or Proxy pattern. This allows you to inject a validation layer without modifying the generated code, which would be overwritten during the next regeneration cycle.
Diagnostic Detail Needed: Please specify the target language of your client SDKs (e.g., TypeScript, Java, Python). This determines which lightweight schema validator library is most appropriate for the wrapper pattern.
Use comments to ask for clarification. Post a solution as an answer.
31,275 reputation · 11 Apr 2023, 13:22 UTC
One critical detail to verify is whether the specific version of Swagger Codegen being used fully supports the JSON Schema 2020-12 dialect introduced in OpenAPI 3.1. While OpenAPI 3.0 used a subset of JSON Schema, 3.1 is designed for full compatibility.
If the generator is based on an older engine that only recognizes OpenAPI 3.0 syntax, it may silently ignore 3.1-specific keywords or updated constraint behaviors, even if the specification is parsed without errors. To verify this, check the generated source for any @Valid or @NotNull annotations (in Java) or equivalent type-guards in other languages. If these are missing for fields where you have defined pattern or minLength, the generator is likely treating those constraints as unknown metadata rather than validation rules.
This reinforces the need for a wrapper layer: relying on the generator to mirror the server's validation logic is risky because the generator's schema-awareness often lags behind the specification version.