Understand APIs and HTTP
Represent requests and interpret responses without making live calls. This module has 3 lessons and takes about 1h 50m. Each lesson has a practice exercise that runs real Python in your browser and a short quiz.
Start module 05 in the Learning LabDescribe an API request
Return a request dictionary for POST /drafts with a JSON Content-Type header and a body containing request_id and text. Do not send it.
An API defines how software asks another service to do something. A request has a method, destination, headers, and sometimes a body. This lesson builds a description only; it sends nothing.
POST commonly submits a new item. Content-Type tells the receiver how to read the body. Here the fixed path is /drafts and the body contains a request id and text.
Keep credentials on a trusted server or in a tool credential store. Never put API keys in browser lesson code or shared notebooks.
See it in action
def solve(request_id, text):
return {"method":"POST", "path":"/drafts", "headers":{"Content-Type":"application/json"}, "body":{"request_id":request_id,"text":text}}
print(solve("r1", "Hello"))
Keep credentials on a trusted server or in a tool credential store. Never put API keys in browser lesson code or shared notebooks.
Interpret response statuses
For an integer status, return validate body for 2xx, consider retry for 429 or 5xx, and stop otherwise.
HTTP status codes describe how a request was handled. Codes from 200 to 299 indicate HTTP success, while 400 usually signals a bad request and 401 signals missing or invalid authentication.
Our learning policy queues 429 and 5xx responses for a bounded retry review. Other non-success codes stop. Actual retries also depend on method, provider guidance, and whether repeating the action is safe.
HTTP success does not guarantee the returned data is valid for your task. Validate the response body too.
See it in action
def solve(status):
if 200 <= status < 300:
return "validate body"
if status == 429 or 500 <= status < 600:
return "consider retry"
return "stop"
print(solve(200))
HTTP success does not guarantee the returned data is valid for your task. Validate the response body too.
Practical: Simulate an API adapter
Return ready for 2xx with a non-empty string draft_id, review for other 2xx bodies, retry for 429 or 5xx, and stop otherwise.
An adapter turns service responses into a small vocabulary used by the rest of your workflow. Here a successful draft response must also contain a non-empty draft_id.
Check status before body fields. A retryable status maps to retry, a bad success body maps to review, and other statuses map to stop. No network request is made.
Keep the simulated adapter separate from a live connector. Add timeouts, credential management, and provider-specific checks before a real integration.
Your experiment plan
Use the browser editor or the notebook. All records and AI responses are fictional. No network calls, credentials, or real messages are used.
- List success, malformed success, rate-limit, and authentication response fixtures.
- Run the example and predict its result before changing it.
- Complete the function in Practice and run the checks. Add your own normal, empty, and failure cases.
- Change a successful response body to a list and confirm it goes to review.
- Save the notebook with your observations and explain one limitation of the simulation.
What to hand in
- A tested API adapter and a table of response outcomes.
- A test table with inputs, expected outputs, actual outputs, and one revision.
Reflect on your results
Which information would you need before enabling a live POST?
The automatic exercise checks the core code behaviour. Review observations and written deliverables yourself or with a mentor.
See it in action
def solve(status, body):
if 200 <= status < 300:
draft_id = body.get("draft_id") if isinstance(body, dict) else None
return "ready" if isinstance(draft_id, str) and draft_id.strip() else "review"
if status == 429 or 500 <= status < 600:
return "retry"
return "stop"
print(solve(201, {"draft_id":"d1"}))
Keep the simulated adapter separate from a live connector. Add timeouts, credential management, and provider-specific checks before a real integration.
Free, open and run by a nonprofit.
This page is part of AI Automation, a free course of 20 modules and 60 lessons in the engineering.fit( ) Learning Lab. The Learning Lab is built and run by engineering.fit( ), a nonprofit founded by Abdullateef Opeyemi Bakare that helps African engineering students gain research experience. You do not need an account or pay a fee to learn.