Phase 3: How the Internet & APIs Actually Work · ~40 minutes · REST · HTTP · curl

REST APIs and Reading Docs Cold

Adding .gitignore after committing your API key doesn't remove it from history. It's still sitting in an earlier commit, retrievable forever — the only real fix is rotating the key.

Hiring signal: Never commits a secret, and knows exactly what to do (rotate, not just delete) if one slips through anyway

What you will learn

Read unfamiliar REST API documentation and make a successful request from it
Use HTTP verbs, status codes, and JSON bodies as the REST convention set they actually are
Explain header-based authentication and why a committed API key is a permanent, not temporary, leak
Identify what a documented API error code means and the correct client-side response

Introduction

Type: Learn Languages: REST, HTTP Prerequisites: Lesson 01 (What Actually Happens When You Load a Page) Time: ~40 minutes

Objective

Learning objectives

Read unfamiliar REST API documentation and make a successful request from it
Use HTTP verbs, status codes, and JSON bodies as the REST convention set they actually are
Explain header-based authentication and why a committed API key is a permanent, not temporary, leak
Identify what a documented API error code means and the correct client-side response

What you're building

Using a real, free, no-key-required API (httpbin.org is fine, or any similar service) as your unfamiliar documentation to read cold:

Make a successful request using the correct verb, path, and any required headers, reading the docs directly rather than guessing
Deliberately trigger at least one documented error response (a missing required header, an invalid parameter) and record exactly what status code and body come back
Reproduce this lesson's .gitignore-too-late scenario in a real, throwaway git repo: commit a fake secret, add .gitignore afterward, and confirm with git log -- <file> that it's still in history
Write api_notes.txt explaining, for the error you triggered, what it means and what a correctly-written client should do in response (retry? fail immediately? ask for different input?)

An API's documentation states: "429 Too Many Requests — you have exceeded your rate limit." Your script just received this. What's the correct immediate response?

429 specifically communicates 'you're sending requests faster than I allow' — a deliberate, intentional server response, not an error condition to route around. Retrying immediately in a tight loop is the worst possible response: it adds more requests exactly when the server just said it has too many, likely extending or worsening the rate limit. The correct response is to slow down and retry later, ideally with an increasing delay — the specific mechanism (exponential backoff) is this phase's next lesson, but the core judgment call (this needs a pause, not more immediate attempts) is answerable directly from what 429 documents about itself.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.