the second one.
the first one with only 0 and 1 is too simple. It is very troublesome to encounter case that needs special treatment.
for example, if the requirement is' user name does not exist'to automatically jump to the registration page, and 'password error' is just a prompt, then the first one will not be enough
I agree with option 2
msg can be thought of as a prompt copy sent by the server.
code thinks it's a fixed error id
first, it becomes msg+code together to indicate an error
.
the first is more convenient for the previous paragraph
I successfully return 0 prompt class error return 1 need special handling case returns other numbers
the first one.
although the second is more specific, it is not necessarily useful. For users, the password is incorrect or the username does not exist. Anyway, it is a mistake, and it is useless for the receptionist to ask for that code.
however, if the front and rear ends are not separated, code and msg alone are not enough, so it is best to add a url field to determine whether the foreground needs to jump.
the third way, for example, when errcode is 10000 indicates success, and in other cases, the meaning of 111021 will be split into "1", "11", and "021". The first 1 represents modules such as index, wap, api, and so on. The second 11 represents the method under the module, and the last 021 represents the number of wrong lines. It's convenient to troubleshoot.
I feel that I am accustomed to what kind of use, and there is nothing I must obey.
in fact, this depends on the team. For example, I wrote an Api, recently. I defined the error return code earlier:
.
$map = [
-1001 => '',
-1002 => '',
-1003 => ''
];
defines such an map error code, where 1 001 represents the module and 001 represents the error code. It's just that at the front desk, as long as you don't return 200 (agreed to return 200 successfully), all others will recognize the error return code. In fact, through 200 (successful),-200 (unsuccessful) is also possible, because the abnormal error in your request must be reported under the same module, so it is not very troublesome to troubleshoot.
some special status codes must be agreed upon. If token expires, you need to log in again
-100 => ''
like this.
response body composition
< table >
< thead > < tr >
< th align= "left" > Field < / th >
< th align= "left" > meaning < / th >
< / tr > < / thead >
< tbody >
< tr >
< td align= "left" > code < / td >
< td align= "left" > the return code after the service is processed by the server, which contains the common response code and the current business-specific code
to form the right
http_code + 3 digits, except for
success , which is indicated by the successful use of
200 , and others, such as
client request permission error
401001
< / td >
< / tr >
< tr >
< td align= "left" > msg < / td >
< td align= "left" > prompt text returned to the client after processing by the server. Of course, the client should not use this
prompt directly, but give it to the user according to the code custom prompt < / td >
< / tr >
< tr >
< td align= "left" > data < / td >
< td align= "left" > the data that needs to be returned after processing the business logic must be an object, not any
scalar value . < / td >
< / tr >
< tr >
< td align= "left" > session < / td >
< td align= "left" > the session here is not the session, in the traditional http but the
identifier of a single session. Because the
client will inevitably encounter data problems in the process of calling API, resulting in difficult debugging, you should put all the request records of
in the log, and then when the client has a problem, locate the session according to the session of the request, and then use postman to replay and debug the request, except for the request log.
you should also save the request log < / td >
< / tr >
< / tbody >
< / table >
Common response code
in addition to the business response code, there should be some common response code
< table >
< thead > < tr >
< th align= "left" > code < / th >
< th align= "left" > example < / th >
< / tr > < / thead >
< tbody >
< tr >
< td align= "left" > 200 < / td >
< td align= "left" > request succeeded < / td >
< / tr >
< tr >
< td align= "left" > 401001 < / td >
< td align= "left" > user
identity invalidation < / td >
< / tr >
< tr >
< td align= "left" > 400001 < / td >
< td align= "left" > request parameter error < / td >
< / tr >
< tr >
< td align= "left" > 404001 < / td >
The < td align= "left" > service has no data < / td >
< / tr >
< / tbody >
< / table >
.
my design plan is:
code:
summary:
data:
key:
timestamp:
nonce:
description:
-
code : status code, using string
- numbers are easy to repeat and not easy to remember. When debugging, you often need to turn the document into a string, such as
failure_password_or_account_error , which is a self-illustrative status code and is not easy to repeat .
- unify
success when successful. Other status codes are globally unique, but the same status codes may appear on each interface.
- if there are inconsistencies in business status, such as
do_something_1 , do_something2 , etc.
- also has some error codes that need to be caught globally, such as
login_status_timeout , login expires.
-
summary : description, which is a description of the status code, usually in Chinese.
- easy to debug,
- can also be used as a copywriter for the frontend to display directly, such as
failure_password_or_account_error . The frontend does not need to catch this error, but directly prompts summary . In this case, the content of sumamry is account or password error , so that the frontend does not need to capture each status code, just a specific one.
- can also prevent the occurrence of new error codes without capture at the front end and supplement the blank copy. For example, the backend suddenly, or the frontend does not catch an error code
error_yo_yo: remote login, please log in again. At this time, the frontend does not capture it temporarily. After all, the summary prompt is displayed by default, so the user will see remote login prompt. Please log in again. Although it is better to skip to the login page, it does not affect the user's operation for the time being.
-
data : this is real data. Return when needed.
-
key : encrypt data to verify whether the parameter has been tampered with
-
timestamp : timestamp, which can be used to encrypt data input parameters and check the backend at the same time.
-
nonce : meaningless random string, combined with timestamp to prevent replay attacks
description:
the above process is directly encapsulated into the network layer, and in conjunction with the model layer, the business of the upper layer can hardly feel the complexity here. For the upper layer, when it is time to capture the status code, it should be captured directly, and when there is no need to capture it, you don't even have to pay attention to it. Expanding the extensibility of details and is the best
.
experience:
this set has been used for about 2 years, and after several revisions and iterations, it spans more than a dozen projects, involving Native Android , ios , js , etc., although many of the above details are not very clear, but almost.
what is appropriate is a good solution. For example, some project interfaces are very simple, but it is a common addition, deletion, modification and search, there is no complex logic, and the error location is simple. The front end does not need to tell the user the specific error content of the back end, just simply prompt the operation error or failure. Then the status code can be very simple, or even 0 # 1 is enough. Large-scale projects need to define the status codes of each module at the beginning, so that it is convenient to locate and capture various types of errors.
is more inclined to the second, and it is also recommended to use the second directly, which is also the inevitable choice for system optimization and robust.
someone upstairs said that it is convenient for the front end. In fact, it is all the same. The correct status code is a 0 , 1 , 200 depending on your habit, and the rest are error codes. For example, I am used to 0 is success, and everything else is abnormal. For the front end, it is nothing more than to judge whether it is 0 or 1 and whether it is 0 or not.
giving detailed errors at the back end of the second solution code can make the error message more accurate. if it is troublesome and meaningless, it can be treated as a unified error prompt for 0 and 1, that is to say, the second scheme is seamlessly compatible with the first .
but once you decide to adopt the first solution, the backend will only give you one error code . If you want to change the second option in the backend, then the amount of code will be considerable
.
