Li Yu: A good restful API should have the following characteristics: The API should be browser-friendly and fit nicely into the web, rather than being incompatible with the web. 1. The browser is the most common and most common rest client. A good restful API should be able to use the browser +html to complete all the tests (no programming language is required). Such APIs can also be easily tested using a variety of automated web functional testing and performance testing tools. Web front-end applications (browser-based Ria apps, mobile apps, and so on) also make it easy to combine the functionality of multiple restful APIs to build mashup class applications.
The resources contained in this API and the operations on the resources should be intuitive and easy to understand, and conform to the requirements of the HTTP protocol. Rest development is also referred to as "resource-oriented development", which shows that abstraction of resources is the core of designing restful APIs. The process of modeling RESTful APIs is similar to object-oriented modeling, which is centered on nouns. These nouns are resources, and any abstract concept that can be named is defined as a resource. The HTTP protocol is not a transport protocol, it actually provides a unified interface for operating resources. For any operation of the resource, it should be mapped to several limited methods of HTTP (commonly used with get/post/put/delete four methods, and the infrequently used Patch/head/options method) above. Therefore, the process of modeling RESTful API can be regarded as an object-oriented modeling process with uniform interface constraints. According to the provisions of the HTTP protocol, the GET method is safe and idempotent, the Post method is neither safe nor idempotent (can be used as all the write operation of the pass formula), PUT, delete methods are unsafe but idempotent. It is reasonable to map the operation of the resource to these four methods, neither excessive use of a method (such as overuse of the Get method or Post method), or adding too many operations so that the four methods of HTTP are not enough. 2. If you find that there are too many operations on the resource so that the HTTP method is not enough, you should consider designing more resources. Designing more resources (and the corresponding URIs) is harmless for restful APIs. This API should be loosely coupled. The RESTful API is designed to include three progressive, low-to-high levels: Resource abstraction, unified interface, and hyper-text driven. It is these three levels that ensure the loose coupling of restful APIs. 3. When designing an Internet-facing API, loose coupling becomes a "must have" strong demand. Tightly coupled APIs are fragile, and once published, neither the server nor the client can evolve continuously. In particular, the server-side, the published interface is not afraid to change, after the change, almost all client applications immediately do not work properly. Rest this architectural style is tightly coupled API antidote, this topic can be discussed very deep, this is not unfolded. Interested readers can refer to "rest combat". The presentation format used in this API should be a common universal format In the RESTful API, the operation of the resource is done indirectly through the representation of the resource passing between the server-side-client. Resources can be expressed in a number of formats, and resource representations in response and requests may be formatted differently. The format of resource representation in the Get/post response, common in HTML, XML, json;post/put requests in the resource presentation format, common with standard HTML form parameters, XML, JSON. 4. These common presentation formats are very easy to handle and have a large number of frameworks and libraries to support. Therefore, unless there is a reasonable requirement, the custom private format is usually not required. Use HTTP response status codes to express various error situations The HTTP response status code is the standard mechanism used by the HTTP protocol to express error conditions in this unified interface. The response status codes are divided into two parts: status code and Reason phase. Both parts are customizable, or you can use the standard status code to customize only the reason phase. 5. If a so-called "RESTful API" returns a $ OK response for any request, an error message is returned in the body of the response, which clearly does not conform to the basic requirements of the rest architectural style of "ensuring operational semantic visibility". This API should be friendly to the HTTP cache 6. Making the best use of HTTP caching is fundamental to restful API scalability. The HTTP protocol is a layered architecture that can insert many intermediate components from the user agent on both ends to Origin server. In many locations throughout the HTTP communication chain, the cache can be set. There is a good caching mechanism in the HTTP protocol, which can be divided into two sets of caching mechanisms: outdated model and validating model. If the API designer has not considered how to take advantage of HTTP caching at all, there are many problems with the scalability of this API. |