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

What are the REST API design styles, 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.

If you look at all the routes currently defined in your application, you will notice that several of them fit the definition of API I used above. Did you find them? I'm talking about several routes that return to JSON, such as the / translate route defined in Chapter 14. The content of this route is encoded in JSON format and uses the POST method when requested. The response to this request is also in JSON format, the server only returns the requested information, and the client is responsible for presenting this information to the user.

Although JSON routes in applications have the "feel" of API, they are originally designed to support Web applications running in browsers. Imagine that if the smartphone APP wants to use these routes, it will not work because it requires the user to log in, which can only be done through the HTML form. In this chapter, I'll show you how to build API that doesn't depend on Web browsers, and don't assume the type of clients that connect to them.

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.

Get client code on demand (CodeOnDemand)

This is an optional requirement that the server can provide executable code in response to the client so that new functionality of the client can be obtained from the server. Because this principle requires an agreement between the server and the client on the type of executable code that the client can run, it is rarely used in API. You might think that the server might return JavaScript code for Web browser clients to execute, but REST is not specifically designed for Web browser clients. For example, if the client is an iOS or Android device, performing JavaScript may cause some complexity.

Unified interface

Finally, the most important, controversial, and ambiguous principle of REST is the unified interface. Dr.Fielding lists four features of the REST unified interface: unique resource identifiers, resource representations, self-descriptive messages, and hypermedia.

Unique resource identifiers are achieved by assigning a unique URL to each resource. For example, the URL associated with a given user could be / api/users/, where is the identifier assigned to the user in the primary key of the database table. Most API can do this very well.

The use of resource representations means that when servers and clients exchange information about resources, they must use the agreed format. For most modern API,JSON formats, it is used to build resource representations. API can optionally support multiple resource representation formats, and in this case, the content negotiation option in the HTTP protocol is a mechanism for client and server to confirm the format.

Self-descriptive messages mean that requests and responses exchanged between the client and the server must contain all the information that the other party needs. As a typical example, the HTTP request method is used to indicate what the client wants the server to do. The GET request indicates that the customer wants to retrieve the resource information, the POST request indicates that the customer wants to create a new resource, the PUT or PATCH request defines the modification to the existing resource, and the DELETE indicates the request to delete the resource. The target resource is specified as the URL of the request and additional information is provided in the HTTP header, the query string portion of the URL, or the request body.

Hypermedia requirements are the most controversial and rarely implemented by API, and those API that implement it are rarely done in a way that satisfies REST purists. Because the resources in the application are interrelated, this requirement requires that these relationships be included in the resource representation so that the client can discover new resources by traversing the relationships, almost in the same way that you find a new page in a Web application by clicking a link from one page to another. Ideally, the client can enter an API without needing any information about the resources in it, and can simply learn about them through hypermedia links. However, unlike HTML and XML, the JSON format commonly used for resource representation in API does not define a standard way to include links, so you have to use custom structures, or one of the JSON extensions like JSON-API,HAL,JSON-LD that tries to address this gap.

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.