“This is the 21st day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021”
Hello, I’m looking at the mountains.
It is well known that every HTTP response comes with an HTTP Status Code, which is used to indicate the Status of the HTTP server response. It is defined by the RFC 2616 specification and is extended by the RFC 2518, RFC 2817, RFC 2295, RFC 2774, AND RFC 4918 specifications. As a Web developer, I’m usually 200, 301, 302, 404, 500, 503, etc. Recently, we are developing some external interfaces (interfaces that call each other between systems within the company, also known as internal Open API). When the interface fails to call, we need to return some status codes. Considering the meaning of using HTTP status codes, we can let the caller know roughly what the problem is through the status codes. No need to re-agree unfamiliar coding rules to facilitate communication and error location. I think my idea is good, but I have encountered some problems in the actual writing. How to use this multi-status code? Use this opportunity to learn what status codes are used for what scenarios, and also record the content of HTTP status codes through this article. In this article, we use a decision tree using the Status codes provided in Choosing an HTTP Status Code — Stop Making It Hard by Michael Kropat to distinguish common Status Code usage scenarios.
Note: This article provides the status information and meaning of HTTP status codes, as well as a common status code decision tree summarized by Michael Kropat.
HTTP definitions follow a rule: the first digit of any status code represents the status of the response. 1 indicates a message. 2 indicates success. 3 indicates redirection. 4 indicates that the request is incorrect. 5 and 6 indicate a server error. The diagram below:
Xx: 1
This type of status code indicates that the request has been accepted and needs to continue processing. This type of response is a temporary response, containing only the status line and some optional response header information, and ending with an empty line. Since no 1XX status code is defined in the HTTP/1.0 protocol, the server forbids sending 1XX responses to such clients except under certain test conditions. In addition, there is no decision tree corresponding to this kind of state code in Michael Kropat’s paper, so this kind of state code is used for understanding.
100: the Continue
The initial request has been accepted and the client should continue to send the rest of the request. (New in HTTP 1.1)
The client should continue to send requests. This temporary response is used to inform the client that some of its requests have been received by the server and have not yet been rejected. The client should continue to send the rest of the request, or ignore the response if the request is completed. The server must send a final response to the client after the request completes.
101: Switching separate Protocols
The server will comply with the client’s request to another protocol (new in HTTP 1.1)
The server has understood the client’s request and will inform the client via the Upgrade header that a different protocol is used to complete the request. After sending the blank line at the end of this response, the server will switch to the protocols defined in the Upgrade header. This should be done only when switching to a new protocol is more beneficial. For example, switching to a new VERSION of HTTP has advantages over an older version, or switching to a real-time and synchronous protocol to deliver resources that take advantage of such features.
102: Processing
Status code extended by WebDAV (RFC 2518), indicating that processing will continue.
2XX: successful. 3XX: redirected
In both cases, the server receives, understands and processes the request content. The decision tree is as follows:
2 xx,
This type of status code indicates that the request has been successfully received, understood, and processed by the server.
200: OK
Everything is fine, and the reply documents for the GET and POST requests follow.
The request was successful, and the desired response header or data body is returned with this response.
201: Created
The server has created the document, and the Location header gives its URL.
The request has been implemented, and a new resource has been created based on the requirements of the request and its URI has been returned with the Location header. If the required resource cannot be created in time, return ‘202 Accepted’.
202: Accepted
The request has been accepted, but processing is not yet complete.
The server has accepted the request but has not yet processed it. Just as it may be denied, ultimately the request may or may not be executed. In the case of asynchronous operations, there is nothing more convenient than sending this status code.
The purpose of a response that returns a 202 status code is to allow the server to accept requests for other processes (such as a batch-based operation that is performed only once a day) without having to keep the client connected to the server until the batch operation is complete. A response that accepts request processing and returns a 202 status code should include in the returned entity some information indicating the current status of the processing, as well as Pointers to a process status monitor or state prediction so that the user can estimate whether the operation has completed.
203: Non-Authoritative Information
The document has returned normally, but some of the reply headers may be incorrect because a copy of the document is used (new in HTTP 1.1).
The server has successfully processed the request, but the entity header meta-information returned is not a defined set valid on the original server, but a local or third-party copy. The current information may be a subset or superset of the original version. For example, metadata containing resources can cause the original server to know a superset of meta-information. Using this status code is not required and is only appropriate if the response would have returned 200 OK without using this status code.
204: No Content
Without a new document, the browser should continue to display the original document. This status code is useful if the user refreshes the page periodically and the Servlet can determine that the user document is sufficiently new.
The server successfully processed the request, but does not need to return any physical content and wants to return updated meta-information. The response may return new or updated meta information in the form of entity headers. If such header information exists, it should correspond to the requested variable.
If the client is a browser, the user browser should retain the page from which the request was sent without any changes to the document view, even though according to the specification new or updated meta-information should be applied to the document in the user’s browser active view.
Because the 204 response is prohibited from containing any message body, it always ends with the first blank line after the header.
205: Reset Content
There is no new content, but the browser should reset what it shows. Used to force the browser to clear form input (new in HTTP 1.1).
The server successfully processed the request and did not return anything. But unlike the 204 response, the response that returns this status code requires the requester to reset the document view. This response is primarily used to reset the form immediately after receiving user input so that the user can easily start another input.
Like the 204 response, this response is disallowed from containing any message body and ends with the first blank line after the header.
206: Partial Content
The client sends a GET request with a Range header, and the server completes it (new in HTTP 1.1).
The server has successfully processed some of the GET requests. HTTP download tools such as FlashGet or Xunlei use this type of response to implement breakpoint continuation or break up a large document into multiple download segments at the same time.
The request must contain a Range header indicating the Range of content the client expects, and may contain if-range as a request condition.
The response must contain the following header fields:
• Content-range indicates the Range of Content returned in the response; For multipart downloads with a Content-Type of Multipart/Byteranges, each multipart should contain a Content-range field indicating the Content Range of the segment. If the response contains Content-Length, its value must match the true number of bytes in the Content range it returns. •Date ETag and/or Content-location, if the same request should have returned 200. •Expires, cache-control, and/or Vary, if their values may differ from those corresponding to other previous responses of the same variable.
If the response request uses if-range strong cache validation, then the response should not contain other entity headers. If the request for this response uses if-range weak cache validation, then the response is prohibited from including other entity headers. This avoids inconsistencies between cached entity content and updated entity header information. Otherwise, the response should contain all of the entity header fields that should have been returned in the 200 response.
If the ETag or Last-Modified headers do not exactly match, the client cache should prohibit combining the 206 response returned with any previously cached content.
207: Multi-Status
The status code, extended by WebDAV(RFC 2518), indicates that the subsequent message body will be an XML message and may contain a series of independent response codes depending on the number of previous sub-requests.
3 xx,
This type of status code indicates that the client needs to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirect targets) are specified in the Location field of this response. The user browser can automatically submit the required subsequent requests without user intervention if and only if the subsequent requests are made using a GET or HEAD method. The client should automatically monitor the infinite loop redirection (for example, A->A, or A->B->C->A), because this results in A lot of unnecessary resource consumption on the server and client. As recommended by the HTTP/1.0 specification, browsers should not automatically access redirects more than five times.
300: Multiple Choices
The document requested by the customer can be found in multiple locations that are already listed in the returned document. If the server wants to propose a preference, it should be indicated in the Location reply header.
The requested resource has a selection of feedback messages, each with its own specific address and browser-driven negotiation message. The user or browser can choose a preferred address for redirection.
Unless this is a HEAD request, the response should include the entity of a list of resource attributes and addresses from which the user or browser can select the most appropriate redirect address. The format of this entity is determined by the format defined by content-Type. The browser may automatically make the most appropriate choice based on the format of the response and the browser’s capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should be performed.
If the server already has a preferred feedback option, specify the FEEDBACK URI in the Location; The browser may use this Location value as the address for automatic redirection. In addition, the response is also cacheable unless otherwise specified.
301: Moved Permanently
The document the customer requested is elsewhere, the new URL is given in the Location header, and the browser should automatically access the new URL.
The requested resource has been permanently moved to the new location, and any future references to this resource should use one of the several URIs returned by this response. If possible, clients with link editing capabilities should automatically change the requested address to the one that is returned from the server. Unless otherwise specified, the response is also cacheable.
The new persistent URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity responding should contain a hyperlink to the new URI with a short description.
If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change.
Note: For some browsers using HTTP/1.0, if they send a POST request and GET a 301 response, subsequent redirects will become GET requests.
302: Move temporarily
Similar to 301, but the new URL should be seen as a temporary replacement, not permanent.
The requested resource temporarily responds to the request from a different URI. Since such redirects are temporary, the client should continue to send future requests to the original address. The response is cacheable only if specified in cache-Control or Expires.
If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change.
Note: Although the RFC 1945 and RFC 2068 specifications do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and use GET to access the URI specified in Location, ignoring the original request method. Status codes 303 and 307 have been added to specify what the server expects from the client.
The corresponding status message in HTTP1.0 is “Moved Temporatily”. When this status code appears, the browser automatically accesses the new URL, so it’s a useful status code. Note that this status code can sometimes be substituted for 301. For example, if the browser incorrectly requests http://host/~user (missing the trailing slash), some servers return 301 and others 302. Strictly speaking, we can only assume that the browser automatically redirects only when the original request is a GET. For details, see 307.
303: See Other
Similar to 301/302, except that if the original request was POST, the redirected target document specified by the Location header should be extracted via GET (new in HTTP 1.1).
The response to the current request can be found at another URI, and the client should access that resource using GET. This method exists primarily to allow the output of POST requests activated by the script to be redirected to a new resource. This new URI is not a substitute reference to the original resource. At the same time, 303 responses are prohibited from being cached. Of course, the second request (redirection) may be cached.
Note: Many browsers prior to HTTP/1.1 do not understand 303 status correctly. If you need to consider interactions with these browsers, the 302 status code should do the job, because most browsers handle 302 responses exactly as the specification requires clients to handle 303 responses.
304: Not Modified
The client has the buffered document and makes a conditional request (typically providing an if-modified-since header to indicate that the client only wants to update the document after the specified date). The server informs the client that the cached document can still be used.
If the client sends a conditional GET request and the request is granted, the content of the document has not changed (since the last access or according to the conditions of the request), the server should return this status code. The 304 response disallows the inclusion of a message body and therefore always ends with the first blank line after the message header.
The response must contain the following header information:
•Date, unless the server does not have a clock. If the clock-less server follows these rules, the proxy server and client can add the Date field to the received response header (as specified in RFC 2068), and the caching mechanism will work fine. •ETag and/or Content-location, if the same request should have returned 200. •Expires, cache-control, and/or Vary, if their values may differ from those corresponding to other previous responses of the same variable.
If this response request uses strong cache validation, then this response should not contain other entity headers; Otherwise (for example, if a conditional GET request uses weak cache validation), the response is prohibited from including other entity headers. This avoids inconsistencies between cached entity content and updated entity header information.
If a 304 response indicates that an entity is not currently cached, the caching system must ignore the response and repeat the request without the constraint.
If a 304 response is received asking to update a cache entry, the cache system must update the entire entry to reflect the values of all fields updated in the response.
305: Use Proxy
The document requested by the customer should be extracted via the proxy server specified in the Location header (new in HTTP 1.1).
The requested resource must be accessed through the specified proxy. The Location field gives the URI information for the specified proxy, and the receiver needs to send a separate request repeatedly to access the resource through this proxy. Only the original server can establish the 305 response.
Note: RFC 2068 does not specify that the 305 response is to redirect a single request and can only be established by the original server. Ignoring these restrictions can have serious security consequences.
306 (Outdated) : Switch Proxy
In the latest version of the specification, the 306 status code is no longer used.
307: Temporary Redirect
Same as 302 (Found).
The requested resource temporarily responds to the request from a different URI.
The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity responding should contain a hyperlink to the new URI with a short description. Because some browsers do not recognize the 307 response, you need to add the necessary information so that users can understand and request access to the new URI.
If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change.
Many browsers mistakenly redirect in response to a 302 reply, even though the original request was A POST, and even though it can actually redirect only if the reply to a POST request is 303. For this reason, HTTP 1.1 added 307 to make it clearer to distinguish between several status codes: when a 303 reply occurs, the browser can follow redirected GET and POST requests; If it is 307, the browser can only follow the redirection of the GET request. (New in HTTP 1.1)
4XX: Request error
Such status codes indicate that the client appears to have made an error that interferes with the server’s processing. Unless responding to a HEAD request, the server should return an entity that explains the current error condition and whether it is temporary or permanent. These status codes apply to any request method. The browser should show the user any entity content contained in such an error response. If the client is transmitting data when the error occurs, the server implementation using TCP should be careful to ensure that the client has received the packet containing the error message before closing the connection between the client and the server. If the client continues to send data to the server after receiving an error message, the server’s TCP stack sends a reset packet to the client to clear the client of any unrecognized input buffers before they are read and interfered with by the application on the server.
400: Bad Request
Syntax error in request.
1. The request cannot be understood by the server because the semantics are incorrect. The client should not re-submit this request unless it is modified. 2. The request parameters are incorrect.
401: Unauthorized
The customer attempted unauthorized access to a password-protected page. The response contains a www-Authenticate header, which the browser uses to display the user name/password dialog box and re-issue the request after filling in the appropriate Authorization header.
The current request requires user authentication. The response must include a WWW-Authenticate header applicable to the requested resource to ask for user information. The client can repeatedly submit a request with the appropriate Authorization header information. If the current request already contains Authorization certificates, the 401 response represents server validation that has rejected those certificates. If the 401 response contains the same authentication query as the previous response, and the browser has attempted authentication at least once, the browser should show the user the entity information contained in the response, as this entity information may contain relevant diagnostic information. See RFC 2617.
402: Payment Required
Reserved status code
403: Forbidden
The resource is unavailable. The server understands the client’s request, but refuses to process it. This is usually caused by permission Settings on files or directories on the server.
The server understands the request, but refuses to execute it. Unlike the 401 response, authentication does not help, and the request should not be submitted twice. If this is not a HEAD request and the server wants to be able to explain why the request cannot be executed, the reason for the rejection should be described in the entity. Of course, the server can also return a 404 response if it doesn’t want the client to get any information.
404: Not Found
The resource at the specified location could not be found. This is also a common response.
The requested resource was not found on the server. There is no information to tell the user whether the condition is temporary or permanent. If the server is aware of the situation, it should use the 410 status code to tell the old resource that it is permanently unavailable due to some internal configuration mechanism and that there are no reachable addresses. The 404 status code is widely used when the server does not want to reveal exactly why the request was rejected or when no other suitable response is available. The most likely reason for this error is that the server does not have the page.
405: Method Not Allowed
Request methods (GET, POST, HEAD, DELETE, PUT, TRACE, and so on) are not applicable to the specified resource. (New in HTTP 1.1)
The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header representing a list of request methods that the current resource can accept.
The PUT and DELETE methods write to the resources on the server. Therefore, most web servers do not support these methods or do not allow them under the default configuration. 405 errors are returned for such requests.
406: Not Acceptable
The specified resource has been found, but its MIME type is incompatible with the one specified by the customer in the Accpet header (new in HTTP 1.1).
The content characteristics of the requested resource do not satisfy the condition in the request header, and therefore the response entity cannot be generated.
Otherwise, the response should return an entity with an address list that allows the user or browser to select the most appropriate entity feature from the list. The format of the entity is determined by the media Type defined in the Content-Type header. The browser can make the best choice based on the format and its capabilities. However, the specification does not define any criteria for making such automatic choices.
407: Proxy Authentication Required
Similar to 401, the client must first be authorized by the proxy server. (New in HTTP 1.1)
Similar to the 401 response, except that the client must authenticate on the proxy server. The Proxy server must return a proxy-authenticate for identity questioning. The client can return a proxy-authorization header for authentication. See RFC 2617.
408: Request Timeout
The client has not made any requests during the server license wait time. The customer can repeat the same request at a later date. (New in HTTP 1.1)
The request timed out. The client did not finish sending a request within the time the server was waiting. The client can submit this request again at any time without making any changes.
409: Conflict
Usually associated with PUT requests. The request cannot succeed because it conflicts with the current state of the resource. (New in HTTP 1.1)
The request could not be completed because of a conflict with the current state of the requested resource. This code is allowed to be used only when the user is deemed capable of resolving the conflict and will resubmit a new request. The response should contain enough information for the user to discover the source of the conflict.
Conflicts usually occur in the processing of PUT requests. For example, in an environment where version checking is used, if the version information accompanying a PUT request to modify a particular resource conflicts with a previous (third-party) request, the server should return a 409 error informing the user that the request could not be completed. At this point, the response entity is likely to contain a comparison of the differences between the two conflicting versions so that the user can resubmit the new version after merging.
410: Gone
The requested document is no longer available, and the server does not know which address to redirect to. It differs from 404 in that returning 407 means the document is permanently removed from the specified location, whereas 404 means the document is unavailable for unknown reasons. (New in HTTP 1.1)
The requested resource is no longer available on the server and does not have any known forwarding address. Such conditions should be considered permanent. If possible, clients with link editing capabilities should remove all references to this address with the user’s permission. If the server does not know or cannot determine whether the condition is permanent, the 404 status code should be used. Unless otherwise noted, the response is cacheable.
The main purpose of the 410 response is to help the webmaster maintain the site by notifying the user that the resource is no longer available and that the server owner wants all remote connections to the resource to be removed. Such events are common in time-limited, value-added services. Similarly, the 410 response is used to inform clients that resources that once belonged to an individual are no longer available on the current server site. Of course, it is entirely up to the server owner to mark all permanently unavailable resources as ‘410 Gone’ and to keep that mark for how long.
411: Length Required
The server cannot process the request unless the client sends a Content-Length header. (New in HTTP 1.1)
The server refuses to accept a request without defining the Content-Length header. After adding a valid Content-Length header indicating the Length of the request message body, the client can submit the request again.
412: Precondition Failed
Some preconditions specified in the request header fail (new in HTTP 1.1).
The server failed to meet one or more of the prerequisites when verifying that they were given in the header field of the request. This status code allows a client to set a prerequisite in the request meta-information (request header field data) when acquiring a resource, preventing the request method from being applied to a resource other than its desired content.
413: Request Entity Too Large
The size of the target document is larger than the server is currently willing to process. If the server thinks it can process the request later, it should provide a retry-after header (new in HTTP 1.1).
The server refused to process the current request because the size of entity data submitted by the request was larger than the server was willing or able to process. In this case, the server can close the connection to prevent the client from continuing to send the request.
If the condition is temporary, the server should return a retry-after response header to tell the client how long it can Retry.
414: Request-URI Too Long
The URI is too long (new in HTTP 1.1).
The request URI was longer than the server could interpret, so the server refused to service the request. This is rare. Common cases include:
A form submission that should have used the POST method became a GET method, resulting in an excessively long Query String.
Redirection URI “black holes”, such as the old URI being part of the new one with each redirection, result in the URI being too long after several redirects.
The client is trying to exploit a security vulnerability in some servers. Such servers use a fixed-length buffer to read or manipulate the URI of the request, and when the parameters after GET exceed a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code.
415: Unsupported Media Type
For the currently requested method and requested resource, the submitted entity in the request is not in a format supported by the server, so the request is rejected.
416: Requested Range Not Satisfiable
The server could not satisfy the Range header specified by the customer in the request. (New in HTTP 1.1)
If the request contains a Range header, any data Range specified in the Range does not overlap with the available Range of the current resource, and If an IF-range header is not defined in the request, the server should return a 416 status code.
If Range uses a byte Range, then the first byte positions of all data ranges specified by the request exceed the length of the current resource. The server should also return a 416 status code with a Content-Range entity header that indicates the length of the current resource. The response is also disallowed from using multipart/ Byteranges as its content-Type.
417: Expectation Failed
The expected content specified in request header Expect cannot be satisfied by the server, or the server is a proxy server that has clear evidence that Expect’s content cannot be satisfied at the next node of the current route.
421: There are too many connections from your internet address
The number of connections to the server from the current client’s IP address exceeded the maximum allowed by the server. In general, the IP address here refers to the client address seen from the server (such as the user’s gateway or proxy server address). In this case, the connection count calculation may involve more than one end user.
422: Unprocessable Entity
The request was well-formed, but could not be responded to due to semantic errors. (RFC 4918 WebDAV)
423: Locked
The current resource is locked. (RFC 4918 WebDAV)
424: Failed Dependency
The current request failed due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV)
425: Unordered Collection
Defined in the WebDav Advanced Collections draft, but not in the WebDav Sequential Set Protocol (RFC 3658).
426: Upgrade Required
The client should switch to TLS/1.0. (RFC 2817)
449: Retry With
Extended by Microsoft to mean that the request should be retried after the appropriate action has been performed.
5XX, 6XX: Server error
This status code indicates that an error or exception occurs when the server processes the request. It may also indicate that the server realizes that the current hardware and software resources cannot complete the request processing. Unless this is a HEAD request, the server should contain an explanation entity that explains the current error state and whether the state is temporary or permanent. The browser should show the user any entities that are included in the current response. These status codes are applicable to any response method.
500: Internal Server Error
The server encountered an unexpected situation and could not complete the client’s request.
The server encountered an unexpected condition that prevented it from completing processing the request. Typically, this problem occurs when the source code on the server side is faulty.
501: Not Implemented
The server does not support the functionality required to implement the request. For example, a customer makes a PUT request that is not supported by the server.
The server does not support a feature required for the current request. When the server does not recognize the requested method and cannot support its request for any resource.
502: Bad Gateway
When a server, acting as a gateway or proxy, accesses the next server to complete a request, but the server returns an invalid reply.
An invalid response was received from the upstream server when a server working as a gateway or proxy tried to execute the request.
503: Service Unavailable
The server is not responding due to maintenance or heavy load. For example, the Servlet might return 503 if the database connection pool is full. The server can provide a retry-after header when it returns 503.
The server is currently unable to process requests due to temporary server maintenance or overload. The situation is temporary and will recover over time. If the delay time is expected, the response can include a retry-after header to indicate the delay time. If this retry-after information is not given, the client should process it as if it were a 500 response.
Note: the presence of a 503 status code does not mean that the server must use it if it is overloaded. Some servers simply want to deny the client a connection.
504: Gateway Timeout
Used by a server acting as a proxy or gateway to indicate that a reply cannot be received from a remote server in a timely manner. (New in HTTP 1.1)
When a server working as a gateway or proxy tries to execute a request, it fails to receive a response from an upstream server (a server identified by a URI, such as HTTP, FTP, or LDAP) or a secondary server (such as DNS) in a timely manner.
Note: Some proxy servers will return 400 or 500 errors when DNS queries time out
505: HTTP Version Not Supported
The server does not support the HTTP version specified in the request. (New in HTTP 1.1)
The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or will not use the same version as the client. The response should include an entity that describes why the version is not supported and which protocols are supported by the server.
506: Variant Also Negotiates
Extended by the Transparent Content Negotiation Protocol (RFC 2295), this means that the server has an internal configuration error: the requested negotiated argument resource is configured to use itself in transparent content negotiation and is therefore not an appropriate focus in a negotiation processing.
507: Insufficient Storage
The server could not store the content necessary to complete the request. The situation is considered temporary. WebDAV (RFC 4918)
509: Bandwidth Limit Exceeded
The server reached the bandwidth limit. Procedure This is not an official status code, but it is still widely used.
510: Not Extended
The strategy required to acquire the resource is not met. (RFC 2774)
600: Unparseable Response Headers
The source site does not return the response header, only the physical content
At the end of the article to summarize
Microservice architecture has been widely used, and RPC calls between services are indispensable. Generally speaking, we define status bits to identify the response result status of RPC interfaces. At this point, we can combine primary and secondary status bits, with the primary status code adopting HTTP status code and the secondary status code defined according to business. This satisfies the vast majority of RPC requests. However, HTTP status codes should not be used arbitrarily and should conform to the specification so that they can be extended or communicated accurately with each other.
Recommended reading
- What are microservices?
- Microservices programming paradigm
- Infrastructure for microservices
- Feasible solutions for service registration and discovery in microservices
- From singleton architecture to microservice architecture
- How to effectively use Git to manage code in microservices teams?
- Summary of data consistency in microservice systems
- Implementing DevOps in three steps
- System Design Series how to Design a Short Chain Service
- System design series of task queues
- Software Architecture – Caching technology
- Software Architecture – Event-driven architecture
Hello, I’m looking at the mountains. Swim in the code, play to enjoy life. If this article is helpful to you, please like, bookmark, follow. Welcome to follow the public account “Mountain Hut”, discover a different world.