Request validation

Validate every request body, query and path parameter against a schema before the handler runs, and reply 400 with what was wrong. It is the border between untrusted input and your code.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain why validation sits between untrusted input and your code
Validate a body, query and path parameter with a schema
Spot the schema that allows additional properties

In practice

A few lines that show Request validation doing its job.

JavaScript

const createOrder = {
  body: {
    type: "object",
    required: ["items"],
    additionalProperties: false,
    properties: {
      items: { type: "array", minItems: 1, items: {
        type: "object", required: ["sku", "quantity"],
        properties: { sku: { type: "string", minLength: 1 }, quantity: { type: "integer", minimum: 1 } } } },
      note: { type: "string", maxLength: 200 },
    },
  },
};
app.post("/orders", { schema: createOrder }, handler);

The common mistake

Watch for

Allowing additional properties by default. A client can send fields you never meant to accept, such as isAdmin: true, and an unguarded spread into the database writes them.

What to know first

Your roadmap puts these before Request validation, unless you already know them.

How it stays learned

Once a session shows you understand Request validation, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Where it leads

Topics that build on Request validation.

Input sanitisation

Previous in the module← Middleware