FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 05 Exercises and Phase Exit
Exercises and Phase Exit Hands-on HTTP labs, debugging drills and the Phase 05 readiness standard
HTTP is the contract between independent programs.
REQUEST HTTP Client TaskFlow API
PowerShell / browser / later Next.js NestJS + Fastify RESPONSE
method + target + headers + optional body
status + headers + optional body
Figure - HTTP request/response exchange. Phase 05 studies the protocol before Phase 06 introduces a browser cross-origin call.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 05 Exercises and Phase Exit
Hands-on lab - prove that HTTP is no longer magic Do the exercises with the TaskFlow API running independently. Do not open the Next.js frontend. Phase 05 is successful when you can reason from protocol contracts before integration hides details behind fetch helpers.
Level 1 - Follow 1 Create the Todos feature module/controller/service. 2 Implement GET /todos and GET /todos/:id. 3 Implement POST /todos with 201 behavior. 4 Implement PATCH /todos/:id. 5 Implement DELETE /todos/:id with 204. 6 Exercise every route from PowerShell and record method, URL, status and returned content.
Level 2 - Modify Add an optional description field to the in-memory Todo representation. Decide which requests should include it and prove GET/POST/PATCH behavior with PowerShell. Do not add formal DTO files yet.
Level 3 - Implement Add GET /todos?completed=true and GET /todos?completed=false. Parse the query string in the controller and delegate selection to the service. Explain why completed is a query parameter rather than a new route such as /getCompletedTodos.
Level 4 - Engineer Design the HTTP contract for an archive Todo capability. Compare at least two approaches: PATCHing an archived field versus an explicit action endpoint. State your assumptions and choose one based on domain semantics, not on a memorized REST rule.
Debugging drills Scenario What you should diagnose
GET /todo/1 returns 404 Compare path to registered resource route before inspecting service logic.POST /todos returns 400 Inspect exact JSON and Content-Type before changing the server.DELETE returns 204 but PowerShell prints no Recognize that no response content is expected. object
Second DELETE returns 404 Explain why DELETE can still have idempotent semantics despite a different response.
Server restart removes created Todos Identify in-memory persistence as the expected phase limitation.
PATCH succeeds but unknown fields are Identify missing formal validation; do not claim the current boundary is accepted production-complete.
Oral architecture exam ● What is the difference between a resource and a representation? ● Why can the same URL be used with GET and DELETE? ● What does safe mean in HTTP semantics? ● What does idempotent mean?
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 05 Exercises and Phase Exit
Phase 05 exit checklist ● [ ] GET, POST, PATCH and DELETE routes work from PowerShell. ● [ ] you can identify request method, target, headers and content. ● [ ] you can identify response status, headers and content. ● [ ] you can explain safe and idempotent accurately. ● [ ] you use resource-oriented URLs by default. ● [ ] you understand why status codes are part of the contract. ● [ ] you can distinguish a route 404 from a missing-resource 404 through context. ● [ ] you can explain the temporary in-memory limitation without trying to add Prisma early. ● [ ] pnpm run build succeeds after the Todo endpoints are added.
The protocol is now understandable. Phase 06 will finally make the Next.js application call the NestJS API, introduce frontend API configuration, browser network inspection and CORS at the moment cross-origin behavior actually becomes real.
Official source notes Primary protocol reference: RFC 9110 - HTTP Semantics (RFC Editor). Supplemental developer reference: MDN HTTP Reference and HTTP Request Methods. Nest-specific routing and status behavior reference: NestJS Controllers documentation.
This phase teaches HTTP semantics independent of a specific transport version. HTTP/2 and HTTP/3 change framing and transport details, while request methods, target resources, headers, status codes and representation semantics remain the important application-level concepts for this course.
HTTP is the contract joining independently deployed systems. Method, URL, headers, body, status, and response semantics must agree on both sides.
Restate the goal of “Exercises and Phase Exit” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: client → method + URL → headers/body → server contract → status + response. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: A written TaskFlow API contract for tasks with request/response examples and deliberate error semantics.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
POST /tasks HTTP/1.1
Content-Type: application/json
Authorization: Bearer <token>
{"title":"Ship TaskFlow"}
HTTP/1.1 201 CreatedDo not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.
Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.
Without copying the final source, create a second small scenario that applies “Exercises and Phase Exit” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Define success and failure status codes for create, read, update, delete, validation, auth, forbidden, and missing-resource cases.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Using 200 for every outcome
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.