Preliminary understanding of restful (a), feel the understanding of the restful or insufficient, please advise

This is a creation in Article, where the information may have evolved or changed. **1**. RESTful introduction and features rest is the abbreviation for representational state transfer, and the most common features of rest are: resources, unified interfaces, URIs, and stateless. Below one by one detailed: * * (1) * *. * * Resources *: The so-called resource refers to an entity on the Internet, or a specific information on the network. He can be a piece of text, a picture, or a video. The resources are always reflected by some kind of carrier content, the text can be expressed in TXT format, can also be used in HTML format, the picture can be PNG, or it can be JPG format. JSON is now the most commonly used resource representation format. In combination with development practices, we understand resources and data as follows: A resource is a user-oriented set of datasets that are based on JSON or other representation (performance). The expression of resource to information tends to the data in the conceptual model: (1) The resources always take some kind of representation as the carrier of reality, that is, the serialized information (2) The commonly used representation is JSON (recommended, Lightweight) or XML (not recommended), etc. (3) representation is the presentation layer of the rest architecture, the data (especially the database) is a more abstract, more efficient and better data representation of the computer, and the resources and data relationships exist in the logical model as follows:! [Image.png] (https://static.studygolang.com/180125/684fb53fcaef7e1ccc6cba35751ae075.png) * * (2) * *. * * Unified Interface **:restful architecture style rules, data meta-operation, that is crud (data deletion and retrieval operation), corresponding to the HTTP post, GET, put and delete, four action functions as follows: GET (SELECT): Remove resources from the server POST (Create): Create a new resource on the server, PUT (update): Update the resource on the service side (client provides full resource data), PATCH (update): Updates the resource on the service side (the client provides the resource data that needs to be modified), Only partial data is provided compared to put; Delete: Deletes a resource from the server. * * (3) * *. **uri**: A URI can be used to point to a resource, that is, each URI corresponds to a specific resource. To access this URI, the URI becomes the geology or identifier of each step of the resource. In general, each resource has at least one URI corresponding to it, and the most typical URI is the URL. * * (4) * *. * * Stateless * *: so-called non-state, which means that all resources can be located by URI, and that this location is not related to other resources, and will not change due to changes in other resources. * * Personal understanding, this stateless we can refer to the HTTP stateless protocol, the user's operation is not related to the previous step, each time just pass the necessary data to complete the operation * *. For example, we query their own wages, the first need to log in to the company system, fill in the account password information, jump to the query interface to see their wages, this situation we call a state, each step of our operations are dependent on the previous operation, as long as the previous operation is not successful, the subsequent operation can not be carried out If we only need to enter a URL to get the assigned person's salary, then we call this condition stateless, because getting information does not depend on other resources or states. And in this case, we can treat the salary as a resource, which corresponds to a URL, which can be obtained through the Get method in HTTP, which is a typical restful style. The daily picture top thousand words, distinguishes has the state and the stateless state:! [Image.png] (https://static.studygolang.com/180125/97152e5f85995afba2983f9c2dbcc0f9.png)! [Image.png] (https://static.studygolang.com/180125/db3b70865d8498d51bc2d067970a72db.png) **2**. Roa, SOA, rest, and Rpcroa-resource oriented Architecture (resource-oriented architecture), restful architecture-style services are built around resources and are typical ROA. Although Roa does not conflict with SOA, and even regards Roa as a kind of SOA, but because RPC is also an SOA, early documentation often mixes SOA with RPC, so restful architecture-style services are often referred to as the ROA architecture, in order to better differentiate them from RPC. RPC style was once the mainstream of Web service, originally based on the XML-RPC protocol, RPC-style services can not only use the HTTP protocol, but also with TCP/IP or other communication protocols. However, RPC-style service collection development services adopted a large language, especially in the era of mobile internet, RPC-style service is difficult to mobile terminal use. While the service of RESTful style can use JSON or XML to carry the data, the client's development does not depend on the technology of service implementation, and the mobile terminal can use the service conveniently, because the HTTP method does not agree to the borrowing to complete the data operation. This also exacerbates the restful substitution of RPC called WebService's masterGuide. Compare the services of RPC style with restful service:! [Image.png] (https://static.studygolang.com/180126/7ea8df5b72e09cd323e1b84040612ec0.png)! [Image.png] (https://static.studygolang.com/180126/4b00ea8839c537f13e96e22f132c2522.png) **3**. The real rest and hybrid style usually developers do service-related client development, the use of so-called restful services, basically can be divided into the real rest and hybrid two kinds. With our first knowledge point of the four features, is the true sense of restful style, and hybrid style just borrowed some features of the restful style, but the external claim is still a restful style of service. The mainstream usage of the hybrid style is to use the Get method to obtain resources, using the Post method to create, modify and delete resources, hybrid style exists, according to the Great God summary source has two: one situation is because, some open ah this does not really understand what is a restful architecture style, The service that leads to development is specious; the other is because of the historical baggage, the initial development is originally RPC style, halfway to restful style, in this case developers will choose the RPC-style service outsourcing a layer of restful shell, usually this layer of shell only for back to resources service, As a result, the Get method is implemented in restful style, and if the client proposes the following simple create modify delete data requirement, the function is implemented through the most commonly used post in the HTTP protocol. **4**. Authentication Mechanism! [Image.png] (https://static.studygolang.com/180126/29afd933c79efa35ecf24da5634f3541.png) Because RESTful style services are stateless, authentication mechanisms are particularly important. For example, we mentioned above the query wages, only allow the parties with higher permissions to view, if not through the authority authentication mechanism to make a layer of voluntary restrictions, then all the resources are public, for the user becomes very uninsured. The authentication mechanism solves the problem of determining who is the user who accesses the resource; the problem with the permission mechanism is to determine whether the user is authorized to make the additional deletion check. The authority mechanism is usually bound to the business logic of the service, so the authority mechanism needs to be developed within each system, while the authentication mechanism is universal, and the common authentication mechanism is **session auth** (that is, login via user password), **basic auth**, **token auth** and **oauth**. The authentication mechanism commonly used in service development is the latter three kinds. Let us elaborate on these three kinds: * * (1) ****basic Auth**:basic Auth is the simplest authentication method to use with RESTful APIs, just provide a username and password, but because of the risk of exposing the user name password to a third party client, In the production environment, the use of fewer and less. Therefore, when developing a restful API that is open to the outside world, try to avoid basic Auth, but it can be used in the development environment. * * (2) ****token Auth**:token Auth is not commonly used, it differs from the basic auth is that the user name and password are not sent to the server for user authentication, but rather to the server to send a pre-generated token to authenticate the server. So token auth requires a complete set of token creation and management mechanisms on the server side, the implementation of which will add a large number of non-essential server-side development work, not necessarily the mechanism is safe and common, so token auth used not much. * * (3) ****oauth**:oauth (Open License) is an open licensing standard that allows a third-party app to access private resources (such as photos, videos, contact lists) that the user stores on a Web service without having to provide the user name and password to third-party apps. OAuth allows users to provide a token instead of a user name and password to access their data stored in a particular service provider. Each token authorizes a specific third-party system (for example, a video editing site) to access a specific resource (for example, a video in only one album) within a specific period of time (for example, within the next 2 hours). In this way, OAuth allows users to authorize third-party websites to access certain information that they store in other service providers, rather than all content. Thanks to the rigor and security of OAuth, OAuth is now the most common authentication mechanism in the RESTful architecture style, with the RESTful architectural style as standard for enterprise-class services. Currently OAuth has evolved from OAuth1.0 to OAuth2.0, but this is not a smooth transition upgrade, OAuth2.0 in the premise of security to reduce the complexity of client development, therefore, Gevin recommend the use of OAuth2.0 authentication mechanism in combat applications. * * Summary **:** True rest + OAuth is the standard for RESTful services ****basic AUTH only use * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * with correct HTTP method to send the correct request **538 clicks