Request Validation

Request validation defines what a system is willing to accept at an interface. A request contract can specify required fields, supported content types, data types, permitted values, length limits, and relationships between fields. Structural validation checks whether a request matches that contract; semantic validation checks whether its values make sense for the requested operation. For example, an inference request might require a nonempty messages array, a supported model identifier, and an output-token limit within the selected model's supported range.

Cloud applications commonly validate requests at multiple boundaries. An API gateway can reject basic contract violations before invoking a function or container, while application code enforces rules that require configuration, identity context, or external state. Client-side checks improve usability but are not a trusted security boundary because callers can bypass them. Server-side validation remains necessary for custom clients, internal integrations, and messages received from queues.

For a foundation-model integration, expose a stable application-level request format rather than requiring every client to understand each model provider's payload. The backend validates that format, selects an allowed model, and translates the request into the appropriate inference API call. Amazon Bedrock Converse provides a consistent message-oriented interface for supported models, while InvokeModel uses model-specific request bodies. Neither approach eliminates the need to validate application rules, such as supported model-and-feature combinations or tenant-specific limits. Language-specific AWS SDKs simplify request construction and signing, but their validation behavior varies and does not replace application validation.

Amazon API Gateway REST APIs illustrate gateway-level validation. A configured request validator can check required URI, query-string, and header parameters for presence and nonblank values, and validate a request body against an associated model. Parameter checks do not validate parameter types or formats. Body validation depends on the configured model and content-type matching; configure supported content types deliberately and consider a default model where appropriate so an unmatched content type does not bypass the intended checks. Do not assume API Gateway HTTP APIs provide the same built-in request-validation capability as REST APIs. Keep complex cross-field and business-rule validation in application code.

The same contract should apply whether inference runs synchronously or asynchronously. A synchronous handler running in a function, container, or virtual machine can validate input and then call the model through an AWS SDK. For asynchronous processing, validate before placing work on Amazon SQS, and have consumers validate the message envelope and supported schema version before inference. SQS does not validate message bodies against an application schema. Permanently invalid messages should be quarantined or routed through a controlled failure path rather than retried indefinitely; transient downstream failures require a different retry policy.

Validation introduces trade-offs. Strict contracts catch mistakes early but can break older clients when schemas evolve, while overly permissive contracts allow ambiguous inputs to propagate. Version contracts intentionally, test valid and invalid cases, and return useful client-error responses without exposing sensitive payloads. Gateway rejection can save backend execution and model-inference cost, although gateway processing still incurs its own cost. Finally, a structurally valid request can still be unauthorized, malicious, or unsafe: validation is not authentication, authorization, rate limiting, prompt-injection defense, or output validation. Use those controls alongside it, and record validation failures with safe error codes and correlation identifiers rather than routinely logging complete prompts.