Restful style as I understand it

   When I first saw it, I looked at a few examples and thought that this style is easy to understand, it seems to be a fairly simple specification. I have seen several documents recently and have a deeper understanding of restful. I feel that many posts on the Internet are quite similar, and I can only know the truth, but I don’t know why, let alone the ins and outs, so I can’t apply or abandon or even develop a technology well.

   I don't have time to find all kinds of information to summarize. At present, I can only guess these questions based on the clues in some resources and give myself an answer.

   When we do something, the most important thing to mention is the verb + noun. Like getting a book, buying a piece of clothing, checking out a batch of shoes... throw away the shopping bag. So our series of jobs is a series of verbs + nouns.

1. Why was a protocol like http designed?
   When the Internet appeared, the main thing was to face all kinds of small enough nouns, such as text, pictures, sounds, videos, and combine all such small and clear things in Together. Relatively speaking, the number of nouns is very large, but the relative verbs are relatively small.

   And it's obvious that when these jobs are categorized, they are first categorized by item, not by action. Our world is organized by resources, because images are managed by an agency, and no agency manages access to this action.

   Therefore, the http protocol is faced with detailed resources, which must be based on nouns. Because the resource division is small enough, there are relatively few verbs.

2.http is an application protocol, not a transmission protocol
. The    transmission protocol is only to transmit messages and information. The application protocol is the actual specific operation application, so http will design to use the url to display the resource, and use the method to indicate the operation, so it is enough to use such a protocol to implement the application.
   In current practice, web applications are detonated due to the convenience of browsers, so http is regarded as a tool for transmitting parameters. We do not follow the original http design idea, but just pass the parameters over. As for what to do, determined by parameters. For example, you can use the parameters passed by get to do the operations you do in the task, but you can change the data, delete the data, and update the data. Sometimes it's just security or parameter size.
   Due to the misunderstanding of the design intention of http by developers, the inefficient misuse of http, the application layer protocol, as a transport protocol is caused.

3. Why the traditional application did not detonate the restful style
    http application protocol is considered from the vast Internet, but the actual application only starts from a single application such as monolithic, maybe it is on one machine at first, maybe later It's just that the database is split out.
   
    Since the complexity of these applications and the breadth of splitting have not reached a certain level, it has not reached the moment when applications are designed according to the smallest resources. Until now, SOA and microservices are split to a certain degree of fineness, and it is possible to consider It is combined with the original intention of http.

    In traditional applications, there will also be a noun, and usually this noun is only a large module division, and a resource that is not refined. For example, order appears in the url, which is not a basic order object, but a large order module, so for the work of the module, there is a verb operation such as createOrder. Sometimes this verb is not as simple as generating only one piece of data in an order, it may represent the generation of orders and sub-orders, or even try to deduct fees and record consumption. It's a big move out of an out-and-out combination. Thinking about it this way, this design is also a noun + verb design, but it's just a relationship between a large-scale module name and a series of operations.
    Due to the application in such cases, there are not many nouns divided into modules, but verbs are abundant. After all, the module is much smaller than the various operations within the module. HTTP happens to be a combination of many names and few operations, so it is difficult to match each other with fine-grained application protocols like http. Naturally, http is used as a transport protocol.

4. The arrival of microservices and the rise of restful
    With the increasing complexity of software systems, the continuous splitting of applications, and the rise of distributed applications in the Internet environment, software design and http protocol style can have a unified basis .
    If the nouns in your application can be used with only a few actions provided by http, then it is basically in place, and the restful style can be used. Otherwise, it's just a matter of learning.

5. I have to say that the return value design
   http as the application layer protocol, since the restful style has been used, the return value should also follow this style, such as: status 200 (success), 500 (internal server error) and so on design.
   It is also mentioned that the design of this return code is very valuable for learning the design of ordinary return codes. The first is the classification, the large classification such as 100, 200...500, and the sub-classification design such as 404.
   For example, I have seen that some systems design return codes, and one more parameter test fails, so a brand new return code is designed without classification, which is very inconvenient for the caller. Sometimes the caller only wants to test all parameters. If it fails, a general notification will be displayed. If there is no rule, the code must be changed every time there is a new situation, and an if judgment will be added. With collation, the caller can usually not change the code even if there is a new one.