Request Validation at the Edge

Overview

Validating requests at the edge means the gateway checks structure and limits before traffic reaches any service. Obviously bad requests cost almost nothing to reject, and backends see a cleaner stream of input.

How it works

The gateway loads the API contract and applies it per route. A failing request never leaves the edge.

client -> gateway
   1. TLS, auth, rate limit
   2. size limit (e.g. 1 MB), content-type check
   3. validate body against OpenAPI schema for POST /orders
   4a. invalid -> 400 {"error":"items must be an array"}
   4b. valid   -> route to orders-service

Typical checks include allowed methods, required headers, JSON well-formedness, field types, string length and pattern, numeric ranges and maximum array sizes. Publishing schemas from the same OpenAPI file used to generate service stubs keeps both layers aligned. Services still validate again, since they may also receive traffic from queues or internal callers.

Pitfalls

• Treating edge validation as the only layer. Services must still defend themselves.
• Schema drift. Deploy gateway config in the same pipeline as the service contract.
• Overly strict schemas that reject additive fields clients legitimately send after evolution.
• Unbounded body buffering. Enforce limits on size and nesting depth before parsing.
• Leaking internal details in error messages; return concise, uniform errors.

Key takeaways

• Reject malformed and oversized input at the gateway.
• Generate edge schemas from the service contract.
• Keep business and authorisation rules in services.
• Maintain defence in depth; the edge is a first filter, not a wall.