Oh no, it happened again! “Teacher, what does this error mean?”, “Teacher, where is the mistake?”, “Teacher, I don’t understand this error…”, “What is the difference between 400 and 404?”, “I just got a 400 error, and after I changed it, it became a 500 error, why is that?” Whether debugging interfaces on the frontend, troubleshooting issues on the backend, or during daily integration, understanding status codes is an essential skill. Don’t panic, this article will systematically guide you through the high-frequency HTTP status codes, helping you understand the meaning, scenarios, and responses for each type of status code.
1. First, Understand the Basics: The “Classification Logic” of Status Codes
HTTP status codes range from 100 to 599 and are divided into 5 major categories. The first digit of each category represents the “core status”, allowing you to quickly determine the general direction of the request:1xx (Informational): Temporary responses indicating to the frontend that “the request has been received and is being processed”; these are rarely used in business.
2xx (Success): The request was completely successful, and the backend has returned the expected data, with 200 being the most common.
3xx (Redirection): The request has not been completed directly and requires further action from the frontend (such as redirecting to a new address or using cached data), typical codes include 301, 302, and 304.
4xx (Client Error): The issue lies with the frontend, such as incorrect address, accessing a private interface without logging in; the core idea is “the frontend needs to correct and resend”, with common codes being 400, 401, 403, and 404.
5xx (Server Error): The issue lies with the backend, such as code bugs or server downtime; the core idea is “the backend needs to fix it and try again”, with typical codes being 500, 502, and 503.
Remember this classification logic; when encountering unfamiliar status codes, you can quickly locate the problem direction by looking at the first digit—if you see 4xx, check the frontend parameters first; if you see 5xx, let the backend check the logs first.
2. Detailed Explanation of High-Frequency Status Codes: From “Meaning” to “Response Methods”
Below is a compilation of the status codes you will encounter 90% of the time in daily development, each explained with practical scenarios to help you not only “recognize” but also “solve problems”.
1. 2xx Success: Request “All Green Lights”
This category of status codes indicates that “the frontend request format is correct, permissions are sufficient, and the backend processes and returns data normally”; no additional debugging is required, making it the ideal response.
(1) 200 OK: General Success
Meaning: The request was completely successful, and the backend has returned the expected data (for example, a GET request retrieves a list, or a POST request successfully adds data).
Scenario: The frontend sends a <span>GET /users</span> request to retrieve the user list, and the backend returns 200 + user array.
The frontend sends a <span>POST /login</span> request with username and password, and upon successful validation, returns 200 + Token.Note: 200 is “general success”, but in some scenarios, more specific 2xx status codes (as below) are used for clearer semantics.
(2) 201 Created: Resource Created Successfully
Meaning: The frontend sends a request to “add a new resource” (such as POST), and the backend successfully creates the data and returns the result.Scenario: The frontend sends a <span>POST /articles</span> request to submit a new article, and the backend successfully stores it in the database, returning 201 + the new article’s ID and content.
Why not use 200: 201 clearly indicates that “the resource has been created”, which is more precise than 200—if the frontend sees 201, it knows it can redirect to the “newly created article detail page”, while 200 cannot directly distinguish between “successful query” and “successful creation”.
(3) 204 No Content: Success but No Data Returned
Meaning: The request was successful, but the backend does not need to return data (for example, a delete operation).
Scenario: The frontend sends a <span>DELETE /users/123</span> request to delete the user with ID=123, and after successful deletion, the backend returns 204 (no response body).
Frontend Note: When receiving 204, do not attempt to parse the response body (as it is empty); simply execute the “deletion successful” logic (such as refreshing the list).
2. 3xx Redirection: Request “Needs to Take a Detour”
This category of status codes indicates that “the request itself is fine, but the frontend needs to take further action to obtain the result”; the core idea is “redirect” or “use cache”.
(1) 301 Moved Permanently: Permanent Redirection
Meaning: The requested URL has been “permanently moved” to a new address, and all future requests should be sent to the new address.
Scenario: Website domain change: the old domain <span>http://old.com</span> is migrated to the new domain <span>https://new.com</span>; when the frontend sends a <span>GET http://old.com/home</span> request, the backend returns 301 + new address <span>https://new.com/home</span>, and the browser will automatically redirect to the new address, and subsequent visits to <span>old.com</span> will directly use the new address (permanent cache).
Note: 301 is “permanent”; once returned, the browser will cache the new address for a long time—if you want to revert to the old address later, you need to clear the browser cache, otherwise it will keep redirecting.
(2) 302 Found: Temporary Redirection
Meaning: The requested URL is only “temporarily moved” to a new address, and the next request still needs to be sent to the original address.
Scenario: An unauthenticated user accesses a page that requires permissions: the frontend sends a <span>GET /user/profile</span> (user not logged in), and the backend returns 302 + login page address <span>https://xxx.com/login</span>, and the browser redirects to the login page; after the user logs in, the next access to <span>/user/profile</span> will still be sent to the original address (the new address will not be cached).
Difference from 301: 302 is “temporary”; the browser does not cache the new address; 301 is “permanent”; the browser will cache the new address.
(3) 304 Not Modified: Cache Hit
Meaning: The resource requested by the frontend (such as CSS, JS, images) is cached locally and has not expired; the backend tells the frontend “use your local cache directly, no need to transfer the resource again”.
Scenario: The frontend requests <span>GET /css/main.css</span> for the first time, the backend returns 200 + the CSS file, and marks the resource version with <span>ETag</span> or <span>Last-Modified</span>; during the second request, the frontend will include <span>If-None-Match: [last ETag]</span> in the request header, and the backend compares and finds that the resource has not been updated, returning 304, allowing the browser to use the locally cached CSS file directly.Benefit: Reduces server bandwidth consumption and speeds up page loading (no need to repeatedly download the same resource).
3. 4xx Client Error: “Frontend Needs to Check Itself First”
This category of status codes is a “high-frequency pitfall” for frontend debugging, primarily caused by “the frontend request not meeting backend requirements”; modifications to the frontend code or operations are necessary before retrying.
(1) 400 Bad Request: Request Parameter Error
Meaning: The parameters sent by the frontend are incorrectly formatted, missing required fields, or the parameter values do not meet the rules, making it impossible for the backend to process.
Scenario: The backend requires <span>POST /users</span> to include <span>name</span> (string) and <span>age</span> (number), but the frontend sends <span>age: "twenty"</span> (string) or fails to send <span>name</span>, resulting in the backend returning 400 + error message (e.g., “age must be a number”).
Frontend Response:
- 1. First, check the error message in the response body (the backend usually specifies which parameter is incorrect);
- 2. Check the parameter types (for example, do not send strings for numbers), ensure all required fields are present, and verify that parameter values meet the rules (such as phone number format).
(2) 401 Unauthorized: Not Authenticated (Not Logged In)
Meaning: The interface requested by the frontend requires “user login” to access, but the current user is not logged in (or the login status has expired).
Scenario:
- • An unauthenticated user sends a
<span>GET /user/orders</span>request to retrieve the order list, and the backend returns 401; - • The token used during user login has expired, and the request is still using the old token, resulting in the backend returning 401.Frontend Response:
- • Redirect to the login page, prompting the user to log in again;
- • If the token has expired, attempt to use “refresh token” to obtain a valid token (to avoid requiring the user to log in again).
(3) 403 Forbidden: Authenticated but No Permission
Meaning: The user is logged in (the 401 issue has been resolved), but does not have permission to access the current interface (for example, a regular user trying to access an admin interface).Scenario: A regular user sends a <span>DELETE /admin/users</span> request to delete another user, and the backend returns 403 (only administrators have this permission).
Difference from 401: 401 is “not logged in”, while 403 is “logged in but not authorized”.
- • Frontend Response:
- • Inform the user “you do not have permission to access this feature”;
- • Check if a regular user account was mistakenly used or if an interface beyond permissions was accessed.
(4) 404 Not Found: Resource Does Not Exist
Meaning: The URL address requested by the frontend is incorrect, and the backend does not have a corresponding interface or resource.Scenario: The frontend attempts to request <span>GET /users</span>, but mistakenly writes <span>GET /user</span> (missing the s), and the backend does not have the <span>/user</span> interface, returning 404;
The frontend requests <span>GET /images/123.jpg</span>, but the server does not have this image file, returning 404.
Frontend Response:
- 1. First, check if the URL is misspelled (for example, extra or missing characters, and whether the case matches—some backend interfaces are case-sensitive);
- 2. Confirm whether the backend has already deployed that interface (for example, during integration, the backend may not have completed development, and the frontend calls it prematurely).
(5) 405 Method Not Allowed: Request Method Error
Meaning: The HTTP method used by the frontend (such as GET, POST) is not supported by the backend interface (for example, the interface only supports POST, but the frontend used GET).
Scenario: The backend <span>POST /users</span> interface only supports POST method, but the frontend mistakenly used <span>GET /users</span>, resulting in the backend returning 405.
Frontend Response:
- • Check the backend interface documentation to confirm which HTTP methods are supported (GET, POST, or PUT/DELETE);
- • Correct the request method (for example, change GET to POST).
4. 5xx Server Error: “Backend Needs to Investigate the Issue First”
This category of status codes indicates that “the frontend request is fine, but the issue lies with the backend”; there is limited action the frontend can take, mainly to “inform the backend to investigate” or perform “retry” and other fault-tolerant handling.
(1) 500 Internal Server Error: Server Internal Error
Meaning: A bug in the backend code (such as a null pointer, database query error) or a problem with server configuration prevents the request from being processed.
Scenario:
- • In the backend interface, the code has
<span>int a = 1 / 0</span>(division by zero error), which throws an exception during execution, returning 500; - • The backend fails to retrieve data due to an incorrect database password, returning 500.
Frontend Response:
- • Inform the user “the server is busy, please try again later”;
- • Provide the error information (such as request URL, parameters) to the backend, allowing them to check the logs to locate the bug.
(2) 502 Bad Gateway: Gateway Error
Meaning: This usually occurs in architectures with a “gateway layer” (such as Nginx as a gateway); when the gateway receives a frontend request and fails to forward it to the backend server (for example, the backend server is down or the network is unreachable).
Scenario:
- The frontend request passes through the Nginx gateway, which attempts to forward it to the backend Tomcat server, but Tomcat is not started, resulting in Nginx returning 502.
Frontend Response:
- • Try refreshing the page (it may be a temporary network issue);
- • Inform the backend or operations team to check if the backend server is running normally and if the gateway configuration is correct.
(3) 503 Service Unavailable: Service Temporarily Unavailable
Meaning: The server is temporarily unable to process the request (for example, the server is restarting, overloaded, or under maintenance), and will recover after a while.Scenario:
- • During a major promotional event on an e-commerce platform, the server’s concurrent requests exceed the limit, returning 503;
- • The backend server is restarting for updates, and during this time, it receives requests, returning 503.
Frontend Response:
- • Inform the user “the service is under maintenance, please try again later”;
- • Implement an “automatic retry” logic (for example, retry once every 3 seconds, and after 3 retries, prompt failure).
3. Practical Tips: When Encountering Status Codes, Follow These 3 Steps
- 1. Look at the First Digit to Determine Direction: 4xx check the frontend (parameters, login, URL), 5xx check the backend (logs, server), 3xx check for redirects or cache.
- 2. Read the Response Body for Details: Most backends will return specific error reasons in the response body (such as “age must be a number” or “Token has expired”), so prioritize checking this.
- 3. Keep Evidence During Integration: When encountering unfamiliar status codes, take screenshots of the “request URL, parameters, status code, response body” to provide to the backend, facilitating quick problem localization (avoiding disputes of “I say there’s a problem, you say there’s none”).
HTTP status codes are not just “cold numbers”; they are the “communication tools” between the server and the frontend. Mastering the meanings and response methods of high-frequency status codes can help you avoid detours when debugging interfaces and troubleshooting issues—frontend developers no longer need to struggle with “why the request failed”, and backend developers can quickly understand “where the problem lies”. Next time you encounter a status code, first determine the direction based on the “classification logic”, then find the cause based on the scenario, and the problem can be resolved quickly.