REST API (RESTful) based on micro service SpringCloud phase iii project programming | camp

This post is part of the third session of the Nuggets Creators Training Camp.Digg project | Creator Boot Camp phase 3 is underway, “write” to make a personal impact.

📖 the

My journey - is the star of the sea!

How many roads I will walk, how many mountains I will conquer to find myself, how many times I will fail, how many times I will start again, and whether it all makes sense, I will wait patiently, I prepare for myself, the journey that leads to my dreams and hopes. Do not burn yourself out, my stars, wait for me.

RESTful Architecture style overview

In the current Internet environment, with the rise of Docker and other technologies, the concept of “micro-services” is more and more accepted and applied into practice. An increasing number of Web services are gradually unified with RESTful architectural style. If developers do not know RESTful architectural style well, The so-called RESTful apis that are developed are often far from the norm.

This article is my understanding of RESTful architecture style, and I would like to share it with you.

1.RESTful architecture

The RESTful architectural style was first proposed by Roy T. Fielding (head of the HTTP/1.1 protocol expert group) in his doctoral dissertation in 2000. 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 extensibility 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 the enterprise, RESTful apis (also known as RESTful Web services) are increasingly surpassing SOAP as an important means of implementing SOA. Today, RESTful architecture has become standard for enterprise-level services. REST is an acronym for Representational State Transfer, which can be translated as “Representational State transformation.” The biggest features of REST are resources, unified interfaces, URIs, and statelessness.

1.1 resources

A “resource” can be a piece of text, a picture, a song, a service, or a concrete reality. Resources always reflect their content through some carrier, text can be expressed in TXT format, HTML format, XML format, and even binary format; Images can be rendered in JPG format or PNG format; JSON is now the most commonly used resource representation format.

Resources are a set of user-oriented data sets with JSON (or other Representation) as the carrier, and their expression of information tends to be the data in the conceptual model:

1. Resources are always presented in the form of some Representation, that is, serialized information
2. Common representations are JSON or XML
3. Represntation is the representation layer of the REST architecture

In contrast, data (especially databases) is a more abstract, computer-friendly and efficient representation of data, which exists more in the logical model.

1.2 Unified Interfaces

interface

The RESTful architecture style states that meta-operations on data, namely CRUD(CREATE, read, Update, and DELETE) operations, correspond to HTTP methods: GET is used to obtain resources, POST is used to create resources (and can also be used to update resources), PUT is used to update resources, and DELETE is used to DELETE resources. In this way, the interface of data operation is unified. Only HTTP method can be used to complete all data adding, deleting, checking and modifying, as shown in the following figure:

For Request and Response, don’t ignore the Content-type in the HTTP header. Take JSON as an example. If THE API requires the client to pass IN JSON data when sending a request, the server only needs to obtain and parse THE JSON data. However, if the server supports multiple types of data, such as JSON and form-data, Obtain and parse data of different types according to the content-Type in the header when the client sends a request. If the API needs to return JSON data after responding to a client request, add content-type = Application/JSON to the header.

Serialization 和 Deserialization

Serialization and Deserialization are both Serialization and Deserialization. RESTful apis use standardized data formats, such as JSON or XML. For example, when a client sends a request to the server or a corresponding client sends a request to the client, the client transmits the text in JSON format. The most typical example is the instance of class, namely object. Json is only the format of data transmitted on the network when the server and client communicate. Inside the server and client, There are both requirements for converting JSON to native data and converting native data to JSON. Converting native data to JSON is serialization, and converting JSON to native data is deserialization. While some development languages, such as Python, can easily implement serialization and deserialization of their native data types list and dict, for complex apis, the internal implementation always uses objects as data carriers, so ensuring that serialization and deserialization methods are implemented, This is the most important preparation step for developing RESTful apis.

Serialization and deserialization are a hard requirement in RESTful API development, so almost every common development language has one or more excellent open source libraries for serialization and deserialization, so there is no need to create duplicate wheels when developing RESTful apis, just pick a good library. For example, the entity class implements serializer serialization.

Of course, RESTful apis are written for developers to consume, and their naming and structure need to make sense. Therefore, when designing and writing urls, there are certain specifications to follow.

This will be covered in more detail in future articles, so stay tuned!

1.3 the URI

Everyone has his own name, with a name, you can find others, others can find you, this is the basic requirement of communication between people in society. Therefore, in any kind of communication network, users also have their unique user identification, such as fixed phone number in the fixed network, mobile phone number in the mobile network, etc., so as to distinguish different users and communicate. The Uniform Resource Identifier (URI) is the name of an IMS user in an IMS network.

In practice, of course, each resource has at least one URI that corresponds to it. A URI is a URL.

1.4 stateless

Stateless means that all resources can be located by URI, and this location is independent of other resources and does not change with the change of other resources. The difference between stateful and stateless. Such as query staff’s wages, salary if the query is need to login system, enter the query page on salary, perform related operations, wages for how much, is this kind of situation is a state, because every step of the query wages relies on a step before the operation, as long as the prefix is not successful, the subsequent operation will not be able to perform; If you enter a URL to GET the salary of a specified employee, the situation is stateless, because the salary is not dependent on other resources or states, and in this case, the salary of an employee is a resource corresponding to a URL that can be obtained through the GET method in HTTP, which is a typical RESTful style.

1.5 ROA, SOA, and REST

Note: NOT to mention RPC, the RPC style used to dominate Web services; Rpc-style services can be used not only with HTTP, but also with TCP or other communication protocols. The same RPC style service is more constrained by the language used to develop the service. After entering the mobile Internet era, the RPC style of service is hard to use in a mobile terminal, and RESTful style of service, because you can directly in json or XML as the carrier carrying data, HTTP methods for unified interface to complete the data operation, the client's development does not depend on the service implementation technology, the mobile terminal can easily use the service, REST will eventually replace RPC as the dominant web service.

ROA is Resource Oriented Architecture. RESTful services revolve around resources and are typical of ROA architectures (although “A” and “Architecture” overlap, that’s fine). ROA is not in conflict with SOA, ROA is even considered a form of SOA, but since RPC is also SOA and SOA and RPC are often discussed in older papers, blogs, and books, RESTful services are often referred to as ROA architectures and SOA architectures are rarely mentioned. To be more explicitly distinguished from RPC.

2. Authentication mechanism

Because RESTful services are stateless, authentication is especially important. For example, a private resource, only I or a few other authorized users are qualified to see, not through the authority authentication mechanism to do a layer of restrictions on resources, so all resources will be exposed in a public way, very unreasonable, also very dangerous.

Of course, such problems must be solved, to solve the permission problem can be thought of: custom permission authentication, Shiro, SpringSecurity, SpringCloud-aouth authentication.

This series covers only the use of bloggers in projects (Springcloude-oauth2.0 password authentication mode), authority certification center cases are being sorted out, please continue to pay attention to! .

3.OAUTH

OAuth (Open Authorization) is an open authorization standard that allows a user to give third-party applications access to the user’s private resources (such as photos, videos, and contact lists) stored on a Web service without having to provide a user name and password to third-party applications.

OAuth allows users to provide a token, rather than a username and password, to access the data they store with a particular service provider. Each token grants a specific third-party system (for example, a video editing site) access to a specific resource (for example, just a video in a photo album) for a specific period of time (for example, the next 2 hours). In this way, OAuth lets users authorize third-party sites to access specific information they store with another service provider, but not all of it.

Because of OAUTH’s rigor and security, OAUTH is now the most commonly used authentication mechanism for RESTful architectures, which, along with RESTful architectures, are standard for enterprise-level services.

At present, OAuth has developed from OAuth1.0 to OAuth2.0, but the two are not smooth transition upgrade, OAuth2.0 on the premise of ensuring security greatly reduce the complexity of client development, therefore, Gevin suggested that the actual application of OAuth2.0 authentication mechanism.

There are abundant information about OAuth on the Internet. There are also a large number of open source third-party libraries implementing OAuth mechanism. If you are not familiar with OAuth, you can start with the official website of OAuth (think OAuth’s information is so few and difficult to bite when bloggers actually write projects and apply the single signon authority authentication center).

🎉 finally

• The SringCloud project uses the OAUTH2.0 password authentication mode to write the authorization authority. REST + OAuth is RESTful

• It is standard for microservices. We need to design reasonable resources, and need the close cooperation and reasonable division of labor of each team.

• Of course, the most important thing is to make sure that the right HTTP method is used to make the right request for the data.

• For more references, see here:Chen Yongjia’s blog

• Like the small partner of the blogger can add a concern, a thumbs-up oh, continue to update hey hey!