Lesson 1 of 10

HTTP

Every API request a customer sends is an HTTP request. Before you can diagnose why one failed, you need to be fluent in the shape of the protocol itself.

The request/response cycle

A client sends a request; a server sends back a response. That's the whole protocol — everything else is detail on top of this.

A request has a method (what you want to do), a path (what you want to do it to), headers (metadata like auth and content type), and sometimes a body(the data you're sending). A response has a status code (what happened), its own headers, and usually a body describing the result or the error.

Methods

The method tells the server what kind of operation the client intends.

GET

Read a resource. Should not change server state, and is safe to retry or cache.

POST

Create a resource or trigger an action that usually has side effects.

PUT

Replace a resource entirely with the payload sent.

PATCH

Apply a partial update to a resource — only the fields included change.

DELETE

Remove a resource.

Status code families

You don't need to memorize every code — just the family, and a handful of specific ones you'll see constantly.

2xx — Success

The request was received, understood and accepted — e.g. 200 OK, 201 Created, 204 No Content.

3xx — Redirection

Further action is needed to complete the request — e.g. 301 Moved Permanently, 304 Not Modified.

4xx — Client error

Something about the request itself is wrong — e.g. 400 Bad Request, 401 Unauthorized, 404 Not Found.

5xx — Server error

The request was valid, but the server failed while handling it — e.g. 500 Internal Server Error, 503 Service Unavailable.

Exercises

Look at the sanitized request and response below, then work through both exercises.

POST /v1/messages HTTP/1.1
Authorization: Bearer <redacted>
Content-Type: application/json

{
  "to": "+15551234567",
  "body": "Your appointment is confirmed."
}

HTTP/1.1 400 Bad Request
{
  "error": {
    "code": "invalid_recipient",
    "message": "The 'to' field is not a valid phone number"
  }
}

Concept check

Answer in your head first, then click a question to reveal the answer.

Scenario checklist

Work through the sample request/response and check each item off. Progress is saved in your browser.

Identify the HTTP method used in the requestIdentify the status code in the responseExplain what that status code means, in your own wordsName the most likely cause based on the response bodyDescribe the fix or the next diagnostic step you would take

Go deeper

These primers are a starting point. Read the primary sources to build real fluency.

MDN: An overview of HTTPThe protocol from first principles — start here MDN: HTTP request methodsGET, POST, PUT, PATCH, DELETE and the rest, in detail MDN: HTTP response status codesThe full list, organized by family, with meanings MDN: HTTP messagesHow a request and response are actually structured on the wire web.dev: Learn HTTPA guided course that builds on the same fundamentals

Training Notes

What building this project taught me.

A primer links out instead of repeating the docs

The definitions on this page are intentionally short. The goal is enough context to make the MDN pages make sense on a first read, not to replace them.

Reveal-to-check and persisted-checklist are two different exercise shapes

The concept check is throwaway state (useState) since answers aren't meant to be tracked. The scenario checklist reuses the localStorage + useSyncExternalStore pattern from the onboard page's DiagnosticChecklist, under its own storage key prefix so the two don't collide.