Welcome back! In the previous lesson, you learned how to organize your backend code using a service layer. Now, let’s focus on a key part of building reliable APIs: validation — especially when working with item-level endpoints, such as updating or deleting a single task.

When a user sends data to your API (for example, to update a task), you want to make sure that data is correct and safe before you use it. If you skip validation, your app could break or store bad data. In this lesson, you’ll see how to check incoming data for common problems and return helpful error messages if something is wrong.

This is especially important when working with endpoints like PUT and PATCH, which update existing data. These two methods behave differently:

• PUT expects all fields to be sent and replaces the entire object.
• PATCH expects only the fields that should be updated. We’ll validate differently depending on which one the client uses — and that’s where the partial flag comes into play.

Before jumping into validation, let’s take a moment to connect what we’ve already built:

• We have a Task type that defines the structure of our tasks: id, title, content, completed, and optional dueDate.
• We created a service layer (taskService.ts) to isolate task-related operations like getTaskById and updateTaskById. This helps us keep our API routes clean.
• Now, we’re focusing on making sure the data sent to those service functions is valid, especially for update operations (PUT and PATCH).

The updateTaskById function accepts a partial flag that determines whether a full (PUT) or partial (PATCH) update is expected. The validation function we’ll build will use this flag to check the data accordingly.

We’ll focus on the updateTaskById function and how to validate the data it receives.

To make sure only valid data is accepted, we use a function called validateTaskPayload. This function checks the incoming data and returns a list of errors if something is wrong.

Here’s the function:

Let’s break down what this function does:

• Checks if the payload is an object:
  If the data sent is not a JSON object, it returns an error.

• Checks for unexpected fields:
  Only title, content, completed, and dueDate are allowed. If there’s anything else, it adds an error.

Now, let’s see how to use this validation function when updating a task. In our service layer, the updateTaskById function uses validateTaskPayload to check the data before making any changes.

Here’s the relevant part of the code:

What happens here?

1. The function looks for the task by its id.
2. It validates the incoming data using validateTaskPayload.
3. If there are errors, it returns them and does not update the task.
4. If the data is valid, it updates only the fields provided (for partial updates).

Example:

If the data is valid:

When validation fails, it’s important to let the client know exactly what went wrong. Our service returns an error message that lists all the problems found.

Example of a bad request:

Example of a good request:

By returning clear error messages, you help users of your API fix their mistakes quickly.

In this lesson, you learned how to validate data for item-level endpoints in your Task Manager API. You saw how the validateTaskPayload function checks for required fields, correct data types, and unexpected fields. You also learned how to use this function in your update endpoint and how to return helpful error messages when something goes wrong.

Next, you’ll get to practice writing and using validation in your own code. This will help you build more reliable and user-friendly APIs. Good luck, and see you in the practice exercises!