Shulou(Shulou.com)06/03 Report--

REST API design style is what kind of, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Some people may strongly object that the / translate and other JSON routes mentioned above are API routes. Others may agree, but they will also think that they are a poorly designed API. So what are the characteristics of a well-designed API, and why is the above JSON route not a good API route?

You may have heard of RESTAPI. REST (RepresentationalStateTransfer) is an architecture proposed by RoyFielding in his doctoral thesis. In this architecture, Dr.Fielding shows six defined characteristics of REST in a fairly abstract and general manner.

Apart from Dr.Fielding 's paper, there is no authoritative specification about REST, leaving a lot of details for readers to interpret. The topic of whether a given API conforms to the REST specification is often the source of heated debate among REST "purists" who believe that RESTAPI must follow all six characteristics in a very clear way, unlike REST "pragmatists" who simply use the ideas put forward by Dr.Fielding in the paper as guiding principles or suggestions. Dr.Fielding sided with the purist camp and wrote some additional insights in blog posts and online comments to express his vision.

The vast majority of API implementations currently follow the "pragmatic" REST implementation. This is true of most API, including those from "big players" such as Facebook,GitHub,Twitter. Few public API are agreed to be pure REST, because most API do not contain some details that purists believe must be implemented. Although Dr.Fielding and other REST purists have strict rules for judging whether an API is a RESTAPI, it is common for the software industry to use REST in practice.

Stateless

The stateless principle is one of the two most controversial centers between purists and pragmatists in REST. It states that RESTAPI should not save any state when the client sends the request. This means that none of the mechanisms common in Web development can "remember" users as they browse the application page. In a stateless API, each request needs to contain information that the server needs to identify and authenticate the client and execute the request. This also means that the server cannot store any data related to client connections in the database or other forms of storage.

If you want to know why REST needs stateless servers, the main reason is that stateless servers are very easy to scale, and you just need to run multiple server instances behind the load balancer. If the server stores client state, things get more complicated because you have to figure out how multiple servers access and update that state, or to ensure that a given client is always handled by the same server, a mechanism often referred to as sticky sessions.

If you think about the / translate route discussed in the introduction to this chapter, you will find that it cannot be considered a RESTful because the view function associated with this route relies on Flask-Login 's @ login_required decorator, which stores the user's login state in the Flask user session.

Client-server

The client-server principle is fairly simple, and as it literally means, in RESTAPI, the roles of the client and the server should be clearly distinguished. In practice, this means that the client and server are separate processes and, in most cases, communicate using the HTTP protocol over TCP networks.

Hierarchical system

The principle of a hierarchical system is that when a client needs to communicate with the server, it may eventually connect to the proxy server rather than the actual server. Therefore, for the client, there should be no difference in the way it sends requests if it does not connect directly to the server, and in fact, it may not even know whether it is connected to the target server. Again, this principle states that the server is compatible with receiving requests directly from the proxy server, so it must not assume that the other end of the connection must be the client.

This is an important feature of REST because the ability to add intermediate nodes allows application architects to use load balancers, caches, proxy servers, and so on to design large and complex networks that meet a large number of requests.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.