OK

Server perspective

Use 200 when the request completed successfully and the response body represents the result.

When to use

• •Return 200 for successful GET requests with a representation
• •Use it for updates when the response returns the updated resource
• •Use it for actions that succeed and return a useful result
• •Successful GET requests returning data
• •Successful PUT/PATCH requests returning updated resource
• •Successful POST requests when not creating a new resource
• •Successful DELETE requests that return a representation of the outcome

How to respond

• •Return the resource or operation result in the body when one is useful
• •Set Content-Type and cache headers appropriate to the representation
• •200 is heuristically cacheable by default; set Cache-Control to prevent caching when the response is user-specific or should not be stored

Headers to consider

• •No status-specific header is required; include Content-Type, cache validators, and representation metadata when useful.

Response body

• •Usually include the requested resource, updated resource, or action result

Server-side pitfalls

• •Do not use 200 for successful empty responses where 204 communicates the contract better
• •Do not hide partial failure inside a generic 200 unless the API explicitly models batch results
• •Creating new resources (use 201 Created instead)
• •Successful requests with no response body (use 204 No Content)
• •Partial content responses (use 206 Partial Content)

Examples