HTTP Status Codes: 100, 200, 300, 400, 500

HTTP status codes are issued by a server in response to a client’s request. They are grouped into five categories based on the first digit.

1xx – Informational

These indicate that the request was received and understood. They are provisional responses.

• 100 Continue: The server has received the request headers and the client should proceed to send the request body.

2xx – Success

These indicate the request was successfully received, understood, and accepted.

• 200 OK: The request has succeeded.
• 201 Created: A resource has been successfully created.
• 204 No Content: The server successfully processed the request and is not returning any content.

3xx – Redirection

These indicate the client must take additional action to complete the request.

• 301 Moved Permanently: The requested resource has been permanently moved to a new URL.
• 302 Found: The resource is temporarily located at a different URL.
• 304 Not Modified: Indicates the resource has not been modified since the last request.

4xx – Client Errors

These indicate the request contains bad syntax or cannot be fulfilled.

• 400 Bad Request: The server could not understand the request due to invalid syntax.
• 401 Unauthorized: Authentication is required and has failed or has not been provided.
• 403 Forbidden: The client does not have access rights to the content.
• 404 Not Found: The requested resource could not be found.

5xx – Server Errors

These indicate the server failed to fulfill a valid request.

• 500 Internal Server Error: A generic error occurred on the server.
• 502 Bad Gateway: The server received an invalid response from an upstream server.
• 503 Service Unavailable: The server is not ready to handle the request (e.g., overloaded or down for maintenance).

Summary

HTTP status codes provide critical information about the outcome of requests. Understanding these codes helps in debugging and building robust web applications.

Interview angle

• “400 or 422?” - 400 for a malformed request the server can’t parse; 422 for well-formed syntax that fails semantic validation. FastAPI returns 422 for Pydantic failures, which is why it appears so often in Python APIs.
• “401 or 403?” - 401 means unauthenticated (who are you), 403 means authenticated but not permitted (I know who you are and no). Returning 403 for a missing token is a common and confusing mix-up.
• “What should a failed create return?” - 201 with a Location header on success; 409 for a conflict with existing state; 422 for validation. Returning 200 with an error body is the anti-pattern, because clients and proxies can’t act on it.
• “Which 5xx codes matter operationally?” - 503 with Retry-After for deliberate load shedding, 504 for an upstream timeout. Both tell a client to retry later; a bare 500 tells it nothing.