Five years of architects talk about the RESTful architectural style

Under the tide of the mobile Internet, with the rise of technologies such as docker, the concept of "microservices" is more and more accepted and applied in practice, and more and more web services are gradually unified in the RESTful architectural style. If you don’t know much about the architectural style, the so-called RESTful API developed will always look good and not standardized.

This article is my understanding of the RESTful architectural style. I will share it with you. If you have any questions, welcome to discuss.

 

Outline

• 1. RESTful architectural style

• 1.1.1 Resources

• 1.1.2 Unified Interface

• 1.1.3 URI

• 1.1.4 Stateless

• 1.1 Features of the RESTful architectural style

• 1.2 ROA SOA 、 REST 与 RPC

• 1.3 Authentic REST and hybrid style

• 2. Authentication Mechanism

• 2.1 Basic Auth

• 2.2 Token Auth

• 2.3 OAuth

• 3. Summary

 

1. RESTful architectural style

The RESTful architectural style was originally proposed by Roy T. Fielding (head of the HTTP/1.1 Protocol Experts Group) in his 2000 Ph.D. dissertation. HTTP is a typical application of this architectural style. Since its inception, it has been favored by more and more architects and developers for its scalability and simplicity. On the one hand, with the rise of cloud computing and mobile computing, many enterprises are willing to share their data and functions on the Internet; on the other hand, in enterprises, RESTful API (also known as RESTful Web service) is gradually surpassing SOAP and becoming SOA one of the important means. Today, the RESTful architectural style has become the standard for enterprise-level services.

REST is the abbreviation of Representational State Transfer, which can be translated as "representational state transformation". The biggest features of REST are: resources, unified interface, URI and statelessness.

1.1 Features of the RESTful architectural style

1.1.1 Resources

The so-called "resource" is an entity on the network, or a specific information on the network. It can be a piece of text, a picture, a song, a service, in short a concrete reality. Resources always reflect their content through some kind of carrier. Text can be expressed in txt format, HTML format, XML format, or even binary format; pictures can be expressed in JPG format or PNG format; JSON is The most commonly used resource representation format today.

Combined with my development practice, my understanding of resources and data is as follows:

A resource is a set of user-oriented data sets with json (or other Representation) as the carrier. The representation of information by resources tends to be the data in the conceptual model:

• Resources are always displayed with some kind of Representation as the carrier, that is, serialized information

• Commonly used representations are json (recommended) or xml (not recommended), etc.

• Representation is the presentation layer of the REST architecture

Relatively speaking, data (especially database) is a more abstract, more efficient and computer-friendly form of data representation, and more exists in logical models

The relationship between resources and data is as follows:

1.1.2 Unified Interface

The RESTful architectural style stipulates that the meta-operations of data, namely CRUD (create, read, update and delete, that is, data addition, deletion, query and modification) operations, correspond to HTTP methods respectively: GET is used to obtain resources, POST is used to create new resources (or It is used to update resources), PUT is used to update resources, and DELETE is used to delete resources. This unifies the interface of data operations. Only through the HTTP method, all additions, deletions, and changes to data can be completed.

which is:

• GET (SELECT): Retrieve resource(s) from the server.

• POST (CREATE): Create a new resource on the server.

• PUT (UPDATE): Update the resource on the server (client provides complete resource data).

• PATCH (UPDATE): Update resources on the server (the client provides the resource data that needs to be modified).

• DELETE (DELETE): Deletes the resource from the server.

1.1.3 URI

You can use a URI (Uniform Resource Locator) to point to resources, that is, each URI corresponds to a specific resource. To get this resource, just visit its URI, so the URI becomes the address or identifier of each resource.

Generally, each resource has at least one URI corresponding to it, and the most typical URI is URL.

1.1.4 Stateless

The so-called stateless, that is, all resources can be located through URI, and this location has nothing to do with other resources, and will not change due to changes in other resources. Let's take a simple example to illustrate the difference between stateful and stateless. For example, to query the salary of an employee, if you need to log in to the system to query the salary, enter the salary query page, and get the salary after performing the relevant operation, then this is 有状态the case, because each step of querying the salary depends on the previous operation. , as long as the pre-operation is unsuccessful, subsequent operations cannot be performed; if you enter a url to get the salary of the specified employee, this is 无状态the case, because getting the salary does not depend on other resources or states, and in this case, Employee salary is a resource, which is corresponding to a url, and the resource can be obtained through the GETmethod in HTTP, which is a typical RESTful style.

1.2 ROA SOA 、 REST 与 RPC

ROAThat is, the services of Resource Oriented Architecture and RESTful architecture style are revolved around 资源, which is a typical ROA architecture (although "A" and "architecture" are repeated, but it does not matter), although ROA does not conflict with SOA, even ROA is regarded as One of SOA is not a bad idea, but since RPC is also SOA, SOA and RPC are often mixed up in papers, blogs or books for a long time. Therefore, RESTful architecture style services are usually called ROA architecture, and there are very few Mention the SOA architecture for a more explicit distinction from RPC.

The RPC style used to be the mainstream of Web Services. It was originally based on the XML-RPC protocol (a distributed computing protocol for remote procedure call (RPC)), and was gradually replaced by the SOAP protocol (Simple Object Access Protocol). )) to replace; RPC-style services, not only can be used HTTP, but also TCPother communication protocols. However, RPC-style services are greatly constrained by the language used to develop services. For example, in the .NET framework, the traditional way to develop web services is to use WCF. The services developed based on WCF are RPC-style services. The clients who use this service usually To implement it in C#, if you use python or other languages, it is difficult to achieve a client that can communicate directly with the service; after entering the mobile Internet era, RPC-style services are difficult to use in mobile terminals, while RESTful-style services can be directly The data is carried by jsonor xmlas the carrier, and the HTTP method is used as the unified interface to complete the data operation. The development of the client does not depend on the technology of the service implementation, and the mobile terminal can also easily use the service.

The difference between RPC and RESTful is shown in the following two figures:

1.3 Authentic REST and hybrid style

Usually when developers do service-related client development, the so-called RESTful services they use can be basically divided into two categories: 本真RESTand hybrid风格. 本真RESTThat is, the RESTful architectural style I described above has the above four characteristics and is a RESTful style in the true sense; however hybrid风格, it only draws on some of the advantages of RESTful and has some of the characteristics of RESTful, but it is still claimed to be a RESTful style service to the outside world. . (I secretly think that it is precisely because the hybrid style service confuses the concept of RESTful that the concept of authentic REST is proposed in the RESTful architectural style in order to demarcate the boundaries :P)

The most mainstream usage of the hybrid style is to use GETmethods to obtain resources, and to use POSTmethods to create, modify and delete resources. The reason why the hybrid style exists, as far as I know, comes from two sources: one is because some developers do not really understand what the RESTful architectural style is, which leads to the development of services that look different; and the mainstream reason is due to historical burdens—— The service is originally RPC style. Due to the disadvantages of RPC and the advantages of RESTful mentioned above, developers wrap a layer of RESTful shell on the RPC style service. Usually, this shell is only used to obtain resource services, so it will The method is implemented according to the RESTful style GET. If the client puts forward some simple requirements for creating, modifying or deleting data, the POSTcorresponding functions are implemented through the most commonly used methods in the HTTP protocol.

Therefore, when developing RESTful services, if there is no historical baggage, it is not recommended to use the hybrid style.

I have specially sorted out the above technologies. There are many technologies that cannot be explained clearly in a few sentences, so I simply asked a friend to record some videos. Many problems are actually very simple, but the thinking and logic behind them are not simple. It is also necessary to know why. If you want to learn Java engineering, high performance and distributed, explain the profound things in simple language. Friends of microservices, Spring, MyBatis, and Netty source code analysis can add my Java advanced group: 694549689. In the group, there are Ali Daniel's live broadcast technology and Java large-scale Internet technology videos to share with you for free.

Wonderful continue~

2. Authentication Mechanism

Since RESTful-style services are stateless, authentication mechanisms are particularly important. For example, the employee salary mentioned above should be a private resource, and only the employee himself or a few other authorized people are qualified to see it. This is unreasonable and dangerous.

The problem solved by the authentication mechanism is to determine who is the user accessing the resource; the problem solved by the permission mechanism is to determine whether the user is permitted to use, modify, delete or create the resource. The authorization mechanism is usually bound to the business logic of the service, so the authorization mechanism needs to be customized within each system, while the authentication mechanism is basically general, and the commonly used authentication mechanisms include (that is , session authlogin through username and password), basic auth, token authand OAuthThe commonly used authentication mechanisms are the latter three.

2.1 Basic Auth

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifier and login pages. Rather, HTTP Basic authentication uses static, standard fields in the HTTP header which means that no handshakes have to be done in anticipation.

Visit Wikipedia To Read More

In short, Basic Auth is the simplest authentication method to be used with RESTful API. You only need to provide the username and password. However, due to the risk of exposing the username and password to third-party clients, the more it is used in the production environment. less and less. Therefore, when developing an open RESTful API, try to avoid using Basic Auth

2.2 Token Auth

Token Auth is not commonly used. The difference between it and Basic Auth is that the user name and password are not sent to the server for user authentication, but a token generated on the server side in advance is sent to the server for authentication. Therefore, Token Auth requires the server to have a complete set of Token creation and management mechanisms. The implementation of this mechanism will increase a lot of unnecessary server-side development work, and this mechanism may not be safe and universal enough. Therefore, Token Auth uses Not much.

This article will not introduce Token Auth. I personally have limited understanding of this mechanism. Students who are interested in understanding this mechanism may wish to start with this discussion on Stack Overflow.

Here to provide you with a platform for learning and communication, java architect group: 694549689

1. Those with 1-5 work experience, who do not know where to start in the face of the current popular technology, and who need to break through the technical bottleneck can join the group.

2. After staying in the company for a long time, I lived very comfortably, but the interview hit a wall when I changed jobs. Those who need to study in a short period of time and change jobs to get high salaries can join the group.

3. If you have no work experience, but have a solid foundation, you can join the group if you are proficient in the working mechanism of java, common design ideas, and common java development frameworks.

2.3 OAuth

OAuth is an open standard for authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The client then uses the access token to access the protected resources hosted by the resource server. OAuth is commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password.

OAuth is a service that is complementary to and distinct from OpenID. OAuth is also distinct from OATH, which is a reference architecture for authentication, not a standard for authorization. However, OAuth is directly related to OpenID Connect (OIDC) since OIDC is an authentication layer built on top of OAuth 2.0.

Visit Wikipedia To Read More

OAuth (Open Authorization) is an open authorization standard that allows users to allow third-party applications to access private resources (such as photos, videos, contact lists) stored by the user on a web service without providing a username and password to third-party applications.

OAuth allows users to provide a token instead of a username and password to access their data stored with a specific service provider. Each token authorizes a specific third-party system (eg, a video editing website) to access a specific resource (eg, just a video in a certain album) for a specified period of time (eg, within the next 2 hours). In this way, OAuth allows users to authorize third-party websites to access some specific information, but not all content, that they store with another service provider.

It is precisely because of the rigor and security of OAUTH that OAUTH has now become the most commonly used authentication mechanism in the RESTful architectural style, and together with the RESTful architectural style, it has become the standard for enterprise-level services.

At present, OAuth has developed from OAuth1.0 to OAuth2.0, but the two are not a smooth transition upgrade. OAuth2.0 greatly reduces the complexity of client development under the premise of ensuring security. Therefore, Gevin recommends that in practical applications Adopt OAuth2.0 authentication mechanism.

Now there is a lot of information about OAuth on the Internet, and there are also a large number of open source third-party libraries that implement the OAuth mechanism. Students who are not familiar with OAuth can start from the OAuth official website.

3. Summary

• The real REST + OAuth is RESTful is the standard for microservices

• Basic Auth is only used in the development environment

• Well-designed resources

• Make the right request for the data using the right HTTP method