origin

What happened is that I was invited to answer a question on Zhihu. The main question was whether ID could not find whether to use Status 404. I answered early. There were only one or two answers at that time. I thought there was nothing controversial about discussing academic issues in an academic place, which of course should be followed by rules, but I was shocked after a few hours. The support rate of self-made code party was the first, fortunately, the whole 200 party, which we usually see a lot of, was not supported, otherwise it really vomited blood.

Why follow the specification

In general, those who say special cases are handled in a special way and do not stick to norms are mostly ignorant of some knowledge and take this sentence as an excuse for laziness. Actually, there aren’t that many special cases in a project.

To better adapt to various libraries

Most well-developed HTTP request libraries design error-handling procedures according to the RFC specification, although the handling methods vary, and are always documented in the error handling section. The RFC standard provides maximum compatibility with HTTP clients. You say that your CURRENT HTTP client does not handle Status Code, but there is no guarantee that you will not refactor in the future, and that refactoring will not handle Status Code.

Call API using JS or Python is more likely, let’s look at well-known libraries. In JS, the recently popular axios will, by default, classify code outside the 200 series as an exception. In Python, the most popular HTTP clients are requests, which preprocess status code in more detail.

To make it easier for developers

In addition, in terms of managing the team, our principle is to minimize the “specifications” of a project so that it is easier to follow. Where standards can be used, don’t make more complicated rules yourself. Both the maintainer of the server and the consumer of the API are fluid, and it costs everyone who enters a project to be familiar with a bunch of unnecessary custom project specifications.

An easier way is to look at dachang

In fact, to set standards for projects, the most unreliable is to pat their head, a little better is to ask zhihu or forum, a little better is to search Google, the simplest is to directly look at the big factory’s products or specifications ah. An API is an exposed thing, what better place to look for a reference than this? Let’s take a look:

  • Google follows the rules
  • Github complies with specifications
  • By the way, Microsoft’s API specification is really instructive.
  • Twitter follows the rules
  • Ali Cloud complies with regulations
  • In fact, Tencent’s technology is quite chaotic, and every project is different. But the latest unified specification to be implemented is to return all 200 with the error code in the returned value indicating the error.
  • Baidu Cloud complies with regulations

My advice

Many people may be using a very crude Web framework, resulting in the mistake of returning an error code, so the Response Body cannot be returned. In fact, if you return any Status Code other than 204, you should always return the Body.

In the project specification, you can specify that the Status Code conforms to the RFC standard, or you can select a collection and remove some of the less commonly used ones. Then, if the code is not from the 200 series, it must be accompanied by an error structure like this:

{
    "error": "UserNotFound"."message": "The user was not found"
 }
Copy the code

In this way, errors are divided into three layers. The first layer is Status Code, so users can roughly know what the problem is. The second layer of Error is a Key using the agreed English without Spaces, for the user to judge, users can customize the following operations according to the Key. The third layer is messages, and some Key users can decide to display messages directly to end customers.

If you are a microservice project, you need to require that every service, regardless of language, unify the errors like this. If the developer tells you that the framework doesn’t support it, it’s not a good framework, it’s been refactored. A good framework not only lets you customize the error content, but also allows you to customize the so-called “return of the framework’s own error.” Like the route wasn’t found or something.

The last

I really don’t understand why the most ridiculous answer would be to create a status code of 600 and get the number one vote. Do zhihu users have any independent judgment spirit? As long as they pretend to be serious and show some qualifications, even if it is nonsense, everyone will give a thumbs-up. Maybe zhihu is really not suitable to answer technical questions.