luvv to help

Menu

Topic 1 of 7

HTTP Methods And Status Codes

Learn HTTP Methods And Status Codes for free with explanations, exercises, and a quick test (for API Engineer).

Published: January 21, 2026 | Updated: January 21, 2026

Table of Contents

Why this matters

As an API Engineer, you translate business actions into predictable HTTP requests and meaningful responses. Clear use of methods (GET, POST, PUT, PATCH, DELETE) and status codes (2xx, 4xx, 5xx) makes APIs easy to use, cache, observe, and debug.

  • Design routes that map cleanly to actions (list, create, update, delete).
  • Pick status codes that guide clients (201 on create with Location, 404 when missing, 409 on conflicts).
  • Use idempotency to make retries safe and resilient.
  • Communicate rate limits and errors consistently.
Real tasks you will do
  • Shape CRUD endpoints and choose responses for each path.
  • Resolve ambiguity between PUT vs PATCH and 200 vs 204.
  • Implement 429 with Retry-After and 503 during maintenance.
  • Add ETag/If-Match to avoid overwriting concurrent updates.

Concept explained simply

HTTP is a contract: the method tells the server what kind of action you want; the status code tells the client what happened. Headers add context (what was created, when to retry, what media types allowed).

Mental model

  • Safe methods: do not change server state (GET, HEAD, OPTIONS).
  • Idempotent: repeating the same request yields the same result (GET, PUT, DELETE, HEAD, OPTIONS). PATCH is not guaranteed idempotent; POST is not idempotent.
  • Response body optional: 204 No Content means success with no body.

Core HTTP methods (with typical use)

  • GET: Retrieve data. Safe, idempotent. Typical codes: 200, 206, 304, 404.
  • POST: Create or trigger processing. Not idempotent. Typical codes: 201 (with Location), 202, 400, 409, 415, 422.
  • PUT: Full replace of a resource at a known URI. Idempotent. Typical codes: 200 or 204, 201 (if created), 400, 404, 409, 422.
  • PATCH: Partial update. Not guaranteed idempotent. Typical codes: 200 or 204, 400, 404, 409, 422.
  • DELETE: Remove resource. Idempotent. Typical codes: 204, 404.
  • HEAD: Like GET but headers only. Safe, idempotent. Typical codes: 200, 404.
  • OPTIONS: Discover capabilities. Safe, idempotent. Typical codes: 204 with Allow header.

Status codes you will use most

  • 2xx Success: 200 OK (with body), 201 Created (include Location), 202 Accepted (async), 204 No Content (no body), 206 Partial Content.
  • 3xx Redirection: 301/308 Permanent, 302/307 Temporary, 304 Not Modified (conditional GET).
  • 4xx Client errors: 400 Bad Request (malformed), 401 Unauthorized (needs auth), 403 Forbidden, 404 Not Found, 405 Method Not Allowed (include Allow), 409 Conflict (versioning/uniqueness), 410 Gone, 412 Precondition Failed (ETag), 415 Unsupported Media Type, 422 Unprocessable Entity (validation), 429 Too Many Requests (include Retry-After).
  • 5xx Server errors: 500 Internal, 502 Bad Gateway, 503 Service Unavailable (optionally Retry-After), 504 Gateway Timeout.

Worked examples

1) Create and fetch a user
  • POST /users with valid JSON β†’ 201 Created
    Headers: Location: /users/123
    Body: {"id":"123", ...}
  • GET /users/123 β†’ 200 OK with user JSON
  • POST /users with duplicate email β†’ 409 Conflict (explain conflict in body)
  • POST /users with missing required fields β†’ 422 Unprocessable Entity (list validation errors)
2) Full vs partial update
  • PUT /orders/77 with complete representation β†’ 200 OK (return resource) or 204 No Content
  • PUT is idempotent: sending same body again returns same state and 200/204
  • PATCH /orders/77 with {"status":"shipped"} β†’ 200/204 depending on body
  • PATCH not guaranteed idempotent; avoid side-effectful patches
3) Delete semantics
  • DELETE /files/abc β†’ 204 No Content
  • DELETE /files/abc again β†’ 204 No Content (still idempotent) or 404 Not Found (if you choose to signal absence). Pick one policy and document it; many APIs prefer 204 to keep retries smooth.
4) Conditional requests to save bandwidth
  • GET /posts/9 with If-None-Match: "W/\"etag-xyz\""β†’ if unchanged β†’ 304 Not Modified (no body)
  • PUT /posts/9 with If-Match: "etag-xyz" but server has newer version β†’ 412 Precondition Failed

Practical patterns and helpful headers

  • On 201 Created, include Location with the new resource URI.
  • On 405 Method Not Allowed, include Allow: GET,POST,...
  • On 429 Too Many Requests or 503 Service Unavailable, include Retry-After (seconds or HTTP-date).
  • Honor Content-Type on requests and respond with 415 Unsupported Media Type if not supported.
  • Let clients request formats via Accept and respond with 406 Not Acceptable if you cannot fulfill.

Common mistakes and how to self-check

  • Using 200 for everything. Self-check: does your code tell clients what actually happened (created vs updated vs no content)?
  • Returning 500 for client errors. Self-check: could the client fix it? If yes, it is likely 4xx.
  • Confusing PUT and PATCH. Self-check: PUT should accept a full representation; PATCH is partial.
  • Forgetting Location on 201. Self-check: after create, can a client immediately GET the new resource via Location?
  • No Retry-After on 429/503. Self-check: do clients know when to retry?
  • Ignoring idempotency. Self-check: can clients safely retry after a network glitch?

Exercises

Do these before the quick test. You can compare with the solutions and your rationale.

Exercise 1: Design CRUD for a Book resource

Define endpoints, methods, and status codes for common flows. Mirror this in your own notes.

  • List books, get a single book.
  • Create a book (valid, invalid JSON, validation error, duplicate ISBN).
  • Update full book vs partial fields.
  • Delete a book (first time and repeated).
Show a possible solution
  • GET /books β†’ 200 OK
  • GET /books/{id} β†’ 200 OK or 404 Not Found
  • POST /books with application/json β†’ 201 Created; Location: /books/{id}
  • POST /books with invalid JSON β†’ 400 Bad Request
  • POST /books with unsupported media type β†’ 415 Unsupported Media Type
  • POST /books with duplicate isbn β†’ 409 Conflict
  • PUT /books/{id} full body β†’ 200 OK (return resource) or 204 No Content; 404 if missing
  • PATCH /books/{id} partial β†’ 200/204; 404 if missing; 422 for validation errors
  • DELETE /books/{id} β†’ 204 No Content; repeated delete β†’ 204 (or 404, pick one policy)

Exercise 2: Edge cases and headers

Choose the correct status codes and required headers:

  • Client exceeds rate limit.
  • Client sends Content-Type: application/xml to a JSON-only endpoint.
  • Concurrent update: If-Match fails.
  • Maintenance window: service temporarily unavailable.
Show a possible solution
  • Rate limit exceeded β†’ 429 Too Many Requests; include Retry-After: 60
  • Unsupported media type β†’ 415 Unsupported Media Type
  • ETag mismatch β†’ 412 Precondition Failed
  • Maintenance β†’ 503 Service Unavailable; optional Retry-After

Checklist to verify your answers

  • Did you include Location on 201?
  • Did you include Allow on 405 (if used)?
  • Did you include Retry-After on 429/503?
  • Did you use 422 for validation vs 400 for malformed input?

Mini challenge

Design responses for an upload endpoint:

  • POST /uploads to start processing large file (async).
  • Status when processing, when finished, when checksum mismatch.
One way to solve
  • POST /uploads β†’ 202 Accepted; Location: /uploads/{jobId}
  • GET /uploads/{jobId} while processing β†’ 200 OK {"status":"processing"}
  • GET /uploads/{jobId} finished β†’ 303 See Other or 200 with result; if delivered elsewhere include Location
  • Checksum mismatch β†’ 422 Unprocessable Entity

Who this is for

  • Aspiring and practicing API Engineers
  • Backend developers moving from monoliths to public/internal APIs
  • QA/DevOps who need to reason about API behavior

Prerequisites

  • Basic HTTP knowledge (requests, responses, headers)
  • Comfort with JSON
  • Ability to use an HTTP client (curl or GUI tools)

Learning path

  1. Master HTTP methods and status codes (this lesson).
  2. Resource modeling and RESTful design.
  3. Validation and error structures.
  4. Authentication/authorization basics (tokens, scopes).
  5. Idempotency keys, retries, and timeouts.
  6. Pagination, filtering, and sorting conventions.

Practical projects

  • Build a simple Library API with books and authors. Implement 201 with Location, 422 validations, 409 duplicate ISBN.
  • Add optimistic concurrency with ETags on updates (If-Match β†’ 412).
  • Implement rate limiting simulation that returns 429 with Retry-After.

Next steps

  • Refactor one of your endpoints to return the most precise status codes.
  • Add conditional GET with ETag/Last-Modified to a read-heavy resource.
  • Run through the quick test to lock in terminology.

Progress and saving

You can take the quick test right away. Everyone can use it for free; if you are logged in, your progress will be saved automatically.

Practice Exercises

2 exercises to complete

Instructions

Define endpoints, methods, and status codes for a Book resource. Include success and error cases.

  • List books and get single book.
  • Create a book (valid, invalid JSON, validation error, duplicate ISBN).
  • Update full and partial.
  • Delete (first call and repeated call).
Expected Output
A mapping of endpoints to methods and status codes, e.g., POST /books -> 201 Created + Location; POST invalid JSON -> 400; duplicate -> 409; PUT -> 200/204; PATCH -> 200/204; DELETE -> 204; GET missing -> 404.

HTTP Methods And Status Codes β€” Quick Test

Test your knowledge with 10 questions. Pass with 70% or higher.

10 questions70% to pass
REST Principles

Have questions about HTTP Methods And Status Codes?

AI Assistant

Ask questions about this tool