REST API status codes tell a client what happened after it sends a request to a server. This cheat sheet helps students recognize common success, redirect, client error, and server error patterns without memorizing every code. It is useful when building web apps, debugging API calls, or reading API documentation.
Knowing status codes makes programs easier to test, maintain, and troubleshoot.
The most important idea is that each status code family has a general meaning: 2xx means success, 3xx means redirect, 4xx means the client likely made a bad request, and 5xx means the server failed. Common patterns include 200 OK for a successful read, 201 Created after creating a resource, 400 Bad Request for invalid input, 401 Unauthorized for missing authentication, 404 Not Found for a missing resource, and 500 Internal Server Error for unexpected server failure. A good REST API uses both the status code and the response body to explain the result clearly.
Key Facts
- Status code pattern 2xx means the request succeeded, such as 200 OK for a successful GET or 201 Created for a successful POST that made a new resource.
- Status code 204 No Content means the request succeeded but the response body is intentionally empty, often after DELETE or an update that returns no data.
- Status code pattern 3xx means the client must take another action, such as 301 Moved Permanently for a changed URL or 304 Not Modified for cached data.
- Status code 400 Bad Request means the server could not process the request because the client sent invalid syntax, invalid fields, or missing required data.
- Status code 401 Unauthorized means authentication is missing or invalid, while 403 Forbidden means the client is authenticated but does not have permission.
- Status code 404 Not Found means the requested resource does not exist at that endpoint, such as GET /users/999 when user 999 is not in the database.
- Status code pattern 5xx means the server failed to complete a valid request, such as 500 Internal Server Error or 503 Service Unavailable.
- A REST response should match the action: GET usually returns 200, POST that creates a resource usually returns 201, DELETE often returns 204, and invalid input often returns 400.
Vocabulary
- REST API
- A REST API is a web service design style that lets clients use standard HTTP methods to work with resources.
- Status Code
- A status code is a three-digit number in an HTTP response that summarizes the result of a request.
- Resource
- A resource is an object or collection that an API exposes, such as a user, product, order, or message.
- Endpoint
- An endpoint is a specific URL where a client sends an API request, such as /api/users/42.
- Client Error
- A client error is a 4xx response that usually means the request had a problem the client can fix.
- Server Error
- A server error is a 5xx response that means the server failed while trying to handle the request.
Common Mistakes to Avoid
- Using 200 OK for every response is wrong because it hides whether a resource was created, deleted, missing, or rejected.
- Confusing 401 Unauthorized and 403 Forbidden is wrong because 401 means authentication is missing or invalid, while 403 means the user is known but not allowed.
- Returning 404 Not Found for invalid form data is wrong because 400 Bad Request better describes input that fails validation.
- Sending a response body with 204 No Content is wrong because 204 specifically means the response has no body.
- Blaming the client for a 500 error is wrong because 5xx codes describe server-side failure, not a normal validation problem in the request.
Practice Questions
- 1 A client sends GET /api/books/12 and the book exists. Which status code should the API return?
- 2 A client sends POST /api/users with valid data, and the server creates user 58. Which status code is most appropriate?
- 3 A client sends DELETE /api/comments/9, the deletion succeeds, and the server returns no response body. Which status code should be used?
- 4 Explain why an API should not use 200 OK for both a successful request and a missing resource.
Understanding REST API Status Code Patterns
A REST request has several parts that affect the result. The method states the intended action. The URL identifies a collection or one item.
Headers carry details such as login credentials, accepted data format, and caching rules. The body carries data for many create or update requests. A server can reject a request even when its URL is correct.
For example, a request to create a student record may reach the right endpoint but fail because the email field is missing or the date has the wrong format. Careful APIs validate data before changing anything in storage.
The difference between similar methods matters during design. GET should read data without changing it. Repeating a GET should normally give the same kind of result.
PUT usually replaces a resource at a known URL, while PATCH changes only selected fields. DELETE removes a resource or marks it as removed. PUT and DELETE are often designed to be idempotent.
This means sending the same request twice should leave the final server state unchanged after the first successful request. POST is different.
Repeating a POST can create two orders, two comments, or two payments. Real payment systems use idempotency keys to prevent accidental duplicate charges when a network connection fails and a client retries.
A status code is only one part of a useful response. Headers can tell a client where a newly created resource lives, how long data may be cached, or when too many requests have been sent. A response body should give safe, specific information.
For invalid form data, it can name the field and describe the rule that failed. It should not expose passwords, database queries, or internal file paths. This is especially important for server failures.
Users need a clear message, while developers need a request identifier in logs to trace the real cause. The public response can say that a problem occurred without revealing a security weakness.
Students meet these patterns whenever a web page loads data in the background. A weather app may request a forecast. A school portal may submit an assignment.
A game may save progress through an API. Browser developer tools show the network requests behind these actions. When debugging, check the request method, URL, headers, body, status, and response message in that order.
A 404 may mean the path is misspelled, the identifier is wrong, or the route was never built. A 401 often points to an expired login token. A 403 can show that a normal student account is trying to access a teacher-only action.
A 503 may be temporary, so a client can wait before retrying. Good programs handle expected failures instead of assuming every request will work.