Handle failed responses without stale results
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.
Clear stale results before a new request so yesterday’s success cannot masquerade as today’s response.
Handle failed responses without stale results — guided practice
Show useful states for HTTP and parsing errors.
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. Establish old content
Run success and confirm two branch rows.
You should see: Two results are visible.
A prior success creates a meaningful stale-data test.
2. Run an HTTP failure
Choose server-error and load.
You should see: The list clears; status says Could not load hours: HTTP 503.
An error should not leave old rows looking current.
3. Run malformed text
Choose malformed and load.
You should see: The request is 200 but parsing fails; the error message varies by browser.
A successful HTTP status does not guarantee a valid body.
4. Inspect cleanup
Find list.replaceChildren before try and button.disabled=false in finally.
You should see: The list is cleared and the button is restored after failures.
finally performs cleanup for both success and error paths.
What to finish
A state-test note covering success, HTTP error and malformed JSON.
Watch for this
Displaying old successful rows beside a new failure without marking them stale.
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: 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.
Source & access notes · checked 2026-09-12
Opened and inspected on 2026-09-12: 200, 404 and server-error categories.
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.