Gera Tools

HTTP 2xx Success Codes

Deep dive into every HTTP 2xx code with semantics, headers and use cases.

Focused, searchable reference for HTTP 200–299 success status codes covering body rules, key headers, idempotency notes and when each applies in REST and WebDAV APIs.

What is the difference between 200 and 201?

200 OK is a generic success where the body holds the result. 201 Created specifically means a new resource was created and should carry a Location header pointing to it, typically after POST or PUT.

HTTP 2xx success status codes

The 2xx class signals that the client’s request was received, understood, and accepted. Choosing the most specific success code makes your API self-documenting: a 201 tells a client a resource was created, a 204 tells it there is nothing to render, and a 206 tells it the body is only a slice of the whole. Returning a flat 200 everywhere throws this information away. Search the reference above for any code or keyword to see its meaning, expected body, and idempotency notes.

How it works

A status code is the first machine-readable token of an HTTP response (HTTP/1.1 201 Created). The 2xx range is defined mainly by RFC 9110 with WebDAV additions in RFC 4918 and RFC 5842. The most important distinctions are: whether a body is allowed (204 and 205 forbid one), whether a Location header is expected (201), and whether the response is conditional or partial (206 answers a Range request). Idempotency is a property of the method, not the status code: GET and HEAD are always safe, PUT and DELETE are idempotent, while POST generally is not.

Tips and examples

  • Return 201 Created with Location: /orders/42 after creating a resource so clients can fetch it without guessing the URL.
  • Use 204 No Content for DELETE and for PUT updates where echoing the body adds no value — but never put bytes in the body.
  • For large downloads, support Range requests and answer with 206 Partial Content plus a Content-Range header so interrupted transfers can resume.
  • 202 Accepted is your friend for queue-backed work; return a job URL and let clients poll rather than holding the connection open.