Return code specification
It is better to follow a set of return status code rules in a system, even a team and a company, and plan ahead, such as:
0001 ~ 1999 ，2000 ~ 2999，4000 ~ 4999
These code segments can be planned in advance according to service type, work type and architecture level, for example, x~y is the network segment, which segment is used for error code and which segment is used for success code. I feel that it is relatively clear from the architecture level to know whether it is successful or failed at once. then I can also identify the features above the service layer according to the number of other bits, and feel that the combination of these plans has the best effect to give code segments. In this way, the overall planning can be unified.
Relatively mature systems, such as WeChat, some software and websites will have a return status code in all kinds of situations or in all kinds of errors. I know that this status code is available for every service. With so many services in a system, there must be a good return code design specification.
I would like to ask you how to design this standard, what standards to follow and where to find reference materials.
(I remember where I saw the design standard of the interface return code for Meituan-Dianping takeout before, but now I forgot to find it.)
Error code mechanism is not recommended. The WeChat, microblog and other interfaces you see are all provided to the outside world with limited quantities. It is very easy to formulate error codes.
However, for internal systems, especially large systems, it is a waste of time to formulate error codes.
Moreover, the more detailed the error code, the higher the degree of coupling between systems. Imagine that adding an error code to a module will affect the judgment of the program in the whole system.
Personally, I think there should be a few error codes in large application systems. Just like RESTful designed HTTP interfaces, there are less than 10 commonly used error codes. Its detailed error contents are directly displayed in the form of error messages, not defined by error codes. The detailed error code is also designed to judge the error. Instead of looking up the error code table to find the error information according to the error code when encountering the error, it is better to directly transmit the error information.