Validate records before rendering
See this course’s project requirements
A tested local API-response viewer with a request contract, validation rules, six response cases and an honest integration handoff.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Request/response contract with limits.
- Type and status observations.
- Working local viewer.
- Explicit empty/error/validation behavior.
- Six-case test matrix and README.
Review and revise
Use these criteria to check your work and choose what to improve.
- Fields and types are understood.
- Failures do not show stale results.
- All six cases behave as described.
- Simulation and live-integration limits are explicit.
Want more background?
The idea in everyday life
Build a read-only viewer for a fictional library-hours API contract.
Validation checks meaning; rendering presents accepted values without executing them as markup.
Validate records before rendering — guided practice
Reject invalid records and insert response text safely.
Save api-viewer.html from the download and open it in a modern browser. Open its source in a text editor. The complete original file supplies every fixture and function. It simulates GET /hours locally; it does not contact a real library. Reload after edits; restore the supplied file before each lesson unless told otherwise.
1. Try a missing field
Choose missing and load.
You should see: Invalid branch record appears because closes is absent.
Subtracting an absent value would produce a misleading result.
2. Try valid emptiness
Choose empty and load.
You should see: No branches returned appears; no error is shown.
An empty valid list differs from a broken response.
3. Inspect safe text
Find li.textContent and explain why the name is inserted as text.
You should see: A name cannot become HTML through this assignment.
External strings should not be executed as markup.
4. Challenge the interval
Change Central closes from 18 to 9 in success, reload and run success. Restore after observing the error.
You should see: The validator rejects the reversed interval.
Types alone do not enforce closes greater than opens.
What to finish
A validation rule list with observed accepted/rejected cases.
Watch for this
Treating an empty array as a network error or treating valid types as sufficient business validation.
How can I tell I understand it?
Complete the changed case, explain your result, and pass the three application checks.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkOptional course overview video · same video as Lesson 1
APIs for Beginners - How to use an API (Full Course / Tutorial)
From freeCodeCamp.org. Watch here or open it on YouTube .
Optional course overview. Follow the written steps below at your own pace.Tools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-09-12
Opened and inspected on 2026-09-12: JSON types and parsing.
Access: Free public web page; no paid enrollment required.
Reuse: Public reference; link only. LifeStarter prose, exercises and files are independently authored.
Source & access notes · checked 2026-09-12
Opened and inspected on 2026-09-12: Responses, promises and explicit HTTP status checks.
Access: Free public web page; no paid enrollment required.
Reuse: Public reference; link only. LifeStarter prose, exercises and files are independently authored.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.