Giving Your Task Manager API a Consistent Face

Giving Your Task Manager API a Consistent Face | CodeSignal Learn

Welcome: From “It Works” to “It Feels Professional”

Welcome to the final lesson of this course. So far, you’ve built a fully functional Task Manager API: A clear Task model and in-memory store A service layer handling all task CRUD Validation to keep data safe Middleware with API-key protection and logging A UI panel to exercise all endpoints In this last lesson, you’ll polish the API surface itself so it feels consistent and predictable to any client: Introduce response helpers that standardize your JSON shape Refactor your /api/tasks and /api/tasks/[id] routes to use those helpers Add a filter endpoint and a small filtered-tasks page that follow the same response contract You’ll still be using Codex, but now with a focus on refactoring and fine-grained behavior, rather than raw scaffolding.

What We’re Building and Why It Matters

Right now, your routes return JSON directly via NextResponse.json, and different handlers may shape responses slightly differently. That works, but it’s not ideal: Some responses might be { error: '...' }, others raw arrays, others objects with different keys. Your frontend has to remember multiple formats. Adding metadata (like timestamps) requires repeating logic in every route. This lesson introduces a single, predictable contract. Success responses look like: A data field with the payload A meta field with a timestamp Error responses look like: An error field with a clear message A meta field with a timestamp Once this contract is in place and wired into all handlers, every client (your own UI, tests, or external consumers) can rely on the same structure—across collection routes, item routes, and the new filter endpoint.

How We’ll Use Codex in This Lesson

You’ll direct Codex through three main tasks: Implement response helpers in src/lib/responses.ts . Refactor existing routes (/api/tasks and /api/tasks/[id]) to use those helpers and map service errors to specific HTTP status codes. Finish and polish the filter endpoint + UI so they follow the same response shape and behavior patterns. Your prompts should: Explicitly list all files Codex may change (often 1 or 2 files per prompt). Describe the response shapes and status code rules clearly. Emphasize “do not modify any other files”. Ask Codex to show the full updated content for each touched file. JSON {"data": "...", "meta": {"timestamp": "2024-01-01T00:00:00.000Z"}} {"data": "...", "meta": {"timestamp": "2024-01-01T00:00:00.000Z"}} JSON {"error": "...", "meta": {"timestamp": "2024-01-01T00:00:00.000Z"}} {"error": "...", "meta": {"timestamp": "2024-01-01T00:00:00.000Z"}} These examples capture the consistent “face” of your API.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Step 1: Standardizing JSON with Response Helpers

Step 2: Refactoring /api/tasks and /api/tasks/[id] to Use Helpers

Next, you’ll refactor the collection and item routes to use your new helpers consistently. /api/tasks Collection Route The starter version of src/app/api/tasks/route.ts is already partway there (shown above). You’ll ask Codex to: Replace the placeholder createSuccessResponse([], 200) in GET with getAllTasks(): const tasks = getAllTasks(); return createSuccessResponse(tasks, 200); Preserve the inline validation in POST, but make sure all outcomes use the helpers: Validation errors → createErrorResponse(errors.join(' '), 400) Successful creation → createSuccessResponse(newTask, 201) The logic doesn’t change; only the response formatting does. A prompt you might send: Codex, modify only src/app/api/tasks/route.ts. In GET, call getAllTasks() and return the result with createSuccessResponse(tasks, 200). In POST, keep the existing inline validation, but when there are validation errors, return createErrorResponse(errors.join(' '), 400). When the task is created successfully, return createSuccessResponse(newTask, 201). Do not change imports or function signatures. Do not modify any other files. Show the full updated contents of src/app/api/tasks/route.ts. TypeScript// src/app/api/tasks/[id]/route.ts // TODO: Ask Codex to refactor this route to use createErrorResponse and // createSuccessResponse, mapping service errors to HTTP status codes. import { NextRequest, NextResponse } from 'next/server'; import { getTaskById, updateTaskById, deleteTaskById } from '@/lib/services/taskService'; import { createErrorResponse, createSuccessResponse } from '@/lib/responses'; export async function GET(_: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const task = getTaskById(id); if (!task) return createErrorResponse('Task not found', 404); return createSuccessResponse(task); } export async function PUT(req: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const body = await req.json(); const { task, error } = updateTaskById(id, body, false); if (error) { // TODO: Map 'Task not found' to 404, and all other errors to 400 using createErrorResponse. return createErrorResponse(error, 400); } return createSuccessResponse(task!); } export async function PATCH(req: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const body = await req.json(); const { task, error } = updateTaskById(id, body, true); if (error) { // TODO: Same mapping rules as PUT for 404 vs 400. return createErrorResponse(error, 400); } return createSuccessResponse(task!); } export async function DELETE(_: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const success = deleteTaskById(id); if (!success) return createErrorResponse('Task not found', 404); return new NextResponse(null, { status: 204 }); }// src/app/api/tasks/[id]/route.ts // TODO: Ask Codex to refactor this route to use createErrorResponse and // createSuccessResponse, mapping service errors to HTTP status codes. import { NextRequest, NextResponse } from 'next/server'; import { getTaskById, updateTaskById, deleteTaskById } from '@/lib/services/taskService'; import { createErrorResponse, createSuccessResponse } from '@/lib/responses'; export async function GET(_: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const task = getTaskById(id); if (!task) return createErrorResponse('Task not found', 404); return createSuccessResponse(task); } export async function PUT(req: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const body = await req.json(); const { task, error } = updateTaskById(id, body, false); if (error) { // TODO: Map 'Task not found' to 404, and all other errors to 400 using createErrorResponse. return createErrorResponse(error, 400); } return createSuccessResponse(task!); } export async function PATCH(req: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const body = await req.json(); const { task, error } = updateTaskById(id, body, true); if (error) { // TODO: Same mapping rules as PUT for 404 vs 400. return createErrorResponse(error, 400); } return createSuccessResponse(task!); } export async function DELETE(_: NextRequest, { params }: { params: { id: string } }) { const id = parseInt(params.id); const success = deleteTaskById(id); if (!success) return createErrorResponse('Task not found', 404); return new NextResponse(null, { status: 204 }); }

Welcome: From “It Works” to “It Feels Professional”

What We’re Building and Why It Matters

How We’ll Use Codex in This Lesson

Join the 1M+ learners on CodeSignal

Step 1: Standardizing JSON with Response Helpers

Step 2: Refactoring /api/tasks and /api/tasks/[id] to Use Helpers

/api/tasks/[id] Item Route

Step 3: Finishing the Filter Endpoint and Its UI with Consistent Responses

/api/tasks/filter Route

Filtered Tasks Page

Summary: What You’ve Achieved in This Course