OapiCodemode.Proxy.Validator (oapi_codemode v0.5.0)

Validates an intercepted request against the operation's dereferenced schema.

Deliberately shallow: types, required, enums — recursively through objects and arrays, but no oneOf/anyOf/allOf arbitration, no pattern/format checks (v1 scope). Error messages quote the violated schema fragment: the spec is the documentation the model just read, so errors grounded in it are actionable.

Coverage (v1 decision): query, body, and path parameters are validated. Header and cookie parameters are NOT validated — only path bindings come from a source (the matcher) the library controls closely enough to check cheaply; headers/cookies are left to the upstream API to reject.

Also deliberate: unknown/undeclared query parameters and additionalProperties on objects are never rejected. Validation here is a guardrail that catches the model's mistakes against the spec it just read — not a firewall. Anything not covered by the schema passes through unchanged.

Summary

Types

operation()

What validation reads: parameters and request_body.

Functions

validate(op, request \\ %{})

Types

operation()

@type operation() :: OapiCodemode.Operation.t() | OapiCodemode.Resolve.resolved()

What validation reads: parameters and request_body.

A resolved operation (OapiCodemode.Resolve.operation/4) is a plain map, not an %OapiCodemode.Operation{} — refs followed, markers possible — and it is what the proxy validates. The struct is accepted too, for the conformance and parity suites that hold stored operations.

Functions

validate(op, request \\ %{})

@spec validate(
  operation(),
  %{
    optional(:query) => map(),
    optional(:body) => term(),
    optional(:path_params) => map()
  }
) :: :ok | {:error, String.t()}