Suppose that the client sends a request to the server. After verifying the data, the server finds that it does not match the data and needs to return an error.

My understanding is that the client's request process is correct, so even if the data format does not meet the requirements of the server, the server should return a 200 status code, and then bring back an error message in the text, or some json format messages. Attach the real status code to the message.

But after looking at some other people’s interfaces, some people directly returned the 510 status code.

Excuse me, what do you think? Which one is the norm?

Reply content:

Suppose that the client sends a request to the server. After verifying the data, the server finds that it does not match the data and needs to return an error.

But after looking at some other people’s interfaces, some people directly returned the 510 status code.

Excuse me, what do you think? Which one is the norm?

Many interfaces on the Internet are mostly non-compliant. To put it bluntly, they are HTTP services written by a group of people who don’t even understand the HTTP protocol. They have no reference value. So don't dwell on that. The reason why PHP attracts hackers is similar to this reason. I am very grateful that you are willing to delve into this issue. I must commend you for your spirit.

In fact, I recommend you buy this book: "The Definitive Guide to HTTP", which is very suitable for motivated people like you.

In fact, your understanding of this question is biased.

Just because the request process is correct does not mean that the response should be 200. Because you can get a response, it means that there is no problem with the request process . If the request process is incorrect, either a DNS exception or a connection timeout, etc., you won't even be able to see the response code.

So the response code is used to identify the result given by the HTTP server in response to the request.

For this reason, mainly is divided into 2xx, 3xx, 4xx, and 5xx. Those starting with 2 are definitely successful (not just 200), and those starting with 3 are usually normal, but the resources may not come directly from you. Obtained by request, such as 302 redirect, 304 cache not expired, etc.

Here’s the key point, numbers starting with 4 often indicate anomalies in the request, such as the so-called submitted data format is incorrect 400 or 422, the request requires authorization 401, or the request is rejected due to some reason (insufficient permissions or blacklist) 403. If the requested data does not exist or the data does not want to be obtained by the current request, use 404 (very familiar). If the request method is rejected, use 405. For example, you should use PUT to modify data, POST to add data, GET to obtain data, and delete. Use DELETE requests for data, etc. (there are also common OPTIONS and HEAD requests). Of course, response codes starting with 4 are the most common. You can find detailed articles on HTTP status codes in the encyclopedia (no matter what encyclopedia).

Things starting with 5 are mainly server errors. Exceptions that are not caused by request errors are all status codes starting with 5, such as 500 Server Exception and 503 Server Unable to Provide Service.

HTTP status code is defined in a series of RFC standard documents, so it cannot fully adapt to all interface prompt details, but it can fully cover the semantics of most responses. For detailed prompts, a separate status response code is often set in the interface response to make up for the lack of expressiveness of HTTP status codes for detailed issues. For example, the request format is wrong, but a certain parameter is missing or too many parameters are given, and both are 400. If you want the client to clearly know what happened, you need to define something additional in the interface to assist in this kind of situation. .

This question actually needs to be combined with specific application scenarios.

First of all, if your client refers to an App, especially a mobile App, using 200 plus a specific error code is the right choice! This is not more reasonable, but China (well, actually there are also foreign countries) has a national condition called HTTP hijacking. 404 or 500 may be directly hijacked by the operator or others (haha). Any additional http error information you return will not be received by the App. So if you look at the public network protocols of factory A, factory B, and factory T, they will all transmit errors in this way. It’s not that designers or architects don’t understand what Restful and HTTP status codes are.

If it is an internal protocol, service to service, and the environment is guaranteed, you can define errors in a standard, Restful form.

Oh, share your picture, if you have the conditions and prefer the error protocol in the form of standard HTTP status codes.
HTTP protocol return status code specification issue

Various specifications have their own reasons. One of the two status codes you mentioned is to use the http request as the main reference to analyze the status code, and the other is to use your own interface as the main reference to analyze the status code. Both have their own reasons, it depends on the usage scenario

Is it standardized? Or follow the company's lead~. Personally, I prefer to use http status codes to return errors and bring error messages.

Yours is wrong. Although it is not the 200 status code, the other status codes can also have corresponding content or json. I don’t know if you have ever used spring mvc. It seems that this was available in 4.xx. Function, as long as it is used for verification, it will return a 400 status code and return json.

This depends on how your project is regulated! You can follow the http method, or you can set it up yourself! For example, if you receive this error status code, then set a new status code yourself, and then return some information prompts!

It depends on the needs. The overall project specifications shall prevail. If you are personally leading the project, you can also prevail.

Refer to Tencent's WeChat development documentation.
They are all unified interface return values
http status code is basically 200.
Use different error_codes to define errors.

Personal opinion

It is correct to use http status code.

510 I don’t understand, tell me a status code I often write.

http status 400 and 403.

The former means that the request cannot be parsed, usually because there is a problem with the parameters, and most of the time this error does not require writing code to judge, the server program will automatically judge and return this status.

For example, my parameter only allows numbers between 1 and 10 to be passed. If the user makes a random pass, I will return this status code.

The latter means that the user does not have permission to access. In addition to some prohibited access paths set in the configuration, this error often requires writing code to determine permissions.

For example, my backend only allows access from certain IPs and machines with specific request headers, and all other machines return this status code.

If you use 200 + json to return the status code, the meaning of these standard http status codes will be basically useless. The designer had already simplified it to only 200 and 404. Even 404 can use json status code, just use 200 to indicate connected or not.

What are the benefits of status codes?

Modern browsers and search engine crawlers will recognize and partially process http status codes

For example:

The

4xx status code indicates that the current URL is incorrect and has no meaning in sending the request again.
If one of your pages returns http 200 + json 400, it means there is something wrong with its parameters.

Search engines will not parse your custom status code, and will naturally include this data incorrectly.
Some users will jump to pages with incorrect parameters through search engines.

The browser will also not parse your custom status code. The browser will automatically record your access records, and the browser will not save browsing records when it receives status codes such as 400, 403 and 404 ( Chrome is like this, others seem to be similar).

After you return 200, there is a high probability that the user will click on the browser prompt record when entering the URL, and as a result, access the wrong connection again.