RESTful Architectural Style Overview

In the tide of mobile internet, with the rise of technology such as Docker, the concept of "microservices" is becoming more and more accepted and applied in practice, and the increasing Web service is gradually unified in the RESTful architecture style, if the developer is not familiar with the style of restful architecture, The so-called RESTful API is always dubious, not enough specification.

This article is my understanding of the style of restful architecture, and share with you, if there is a problem, welcome the discussion.

Outline

• 1. RESTful architectural style
  • Features of the 1.1 RESTful architecture style
    • 1.1.1 Resources
    • 1.1.2 Unified Interface
    • 1.1.3 URI
    • 1.1.4 No status
  • 1.2 ROA, SOA, rest, and RPC
  • 1.3 True 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 Expert Group) in his 2000 doctoral dissertation. HTTP is a typical application of this architectural style. Since its inception, it has been favored by a growing number of 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, functions on the Internet, on the other hand, in the enterprise, RESTful API (also known as RESTful Web services) has gradually surpassed soap as an important means to realize SOA. Today, the RESTful architecture style has become standard for enterprise-class services.

Rest is the abbreviation for representational state transfer, which can be translated as "presentation level transformation". Some of the biggest features of rest are: resources, unified interfaces, URIs, and stateless.

1.1 RESTful architectural style features 1.1.1 resources

The so-called "resources", is an entity on the network, or is a specific information on the network. It can be a piece of text, a picture, a song, a service, in short, is a concrete reality. Resources always through a carrier to respond to its content, the text can be expressed in the TXT format, can also be used in HTML format, XML format, and even can be used in binary format, images can be in JPG format, can also be used in PNG format, JSON is now the most common resource representation format.

In combination with my development practice, I understand the resources and data as follows:

A resource is a user-oriented set of datasets that are based on JSON (or other representation), and the resource's representation of information tends to the data in the conceptual model:

• Resources are always displayed as vectors of some kind of representation, that is, serialized information
• Commonly used representation are JSON (recommended) or XML (not recommended), etc.
• Represntation is the presentation layer of the rest architecture

In contrast, data (especially databases) is a more abstract, more efficient and friendly form of data representation in a logical model.

The resources and data relationships are as follows:

1.1.2 Unified Interface

The RESTful architecture style specifies that the meta-operations of the data, namely CRUD (Create, read, update, and delete, which are data additions and deletions), correspond to the HTTP method: Get is used to get the resource, post is used to create a new resource (and can also be used to update resources). Put is used to update resources, delete is used to remove resources, so that the interface to unify the data operation, only through the HTTP method, you can complete all additions and deletions to the data work.

That

• GET (SELECT): Remove resources from the server (one or more items).
• POST (Create): Creates a new resource on the server.
• PUT (UPDATE): Updates the resource on the server (the client provides full resource data).
• PATCH (UPDATE): Updates the resource on the server (the client provides the resource data that needs to be modified).
• Delete: Deletes a resource from the server.

1.1.3 URI

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

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

1.1.4 No status

The so-called stateless, that is, all resources, can be located by URI, and this location is not related to other resources, and will not change because of other resources. The difference between a state and a stateless state, give a simple example to illustrate. If you query the wages of employees, if the query salary is required to log in to the system, into the query Payroll page, after performing related operations, to obtain the amount of wages, then this is 有状态 the case, because the query pay each step of the operation is dependent on the previous operation, as long as the predecessor operation is not successful, subsequent operations will not be able to execute If you enter a URL to get the salary of the specified employee, this is 无状态 the case, because the payroll is not dependent on other resources or status, and in this case, the employee's salary is a resource, which corresponds to a URL, and can be obtained through HTTP GET methods. This is typical of restful style.

1.2 ROA, SOA, rest, and RPC

ROAThat is, the resource oriented Architecture,restful architecture-style service revolves around a 资源 typical ROA architecture (although "A" and "schema" are duplicated, but no harm is said), although Roa does not conflict with SOA, Even consider Roa as a kind of SOA, but because RPC is also SOA, a little bit older papers, blogs or books also often mix SOA with RPC to discuss, so the RESTful architecture style of service is often called the Roa architecture, rarely mention the SOA architecture, So that it is more explicitly differentiated from RPC.

RPC style was once the mainstream of the Web service, initially based on the XML-RPC Protocol (a distributed computing protocol for Remote Procedure calls (procedure Call,rpc), which was later gradually being the SOAP protocol (Simple Object Access Protocol Object Access Protocol) replaces RPC-style services that are not only available HTTP , but can also be used TCP or other communication protocols. RPC-style services, however, are much more constrained by the adoption of language by development services, such as the. NET Framework, where the traditional way to develop a Web service is to use WCF, a WCF-developed service that is RPC-style, and the client that uses the service is typically implemented in C #, If you use Python or other languages, it is difficult to implement directly with the service communication client; After entering the era of mobile internet, RPC style service is difficult to use in mobile terminal, while RESTful style service, because it can json xml carry data directly or for carrier, Using HTTP as a unified interface for data manipulation, client development is not dependent on the technology of service implementation, the mobile terminal can also easily use the service, which also aggravates the rest to replace RPC as a Web service leader.

The difference between RPC and restful is shown in the following two diagrams:

1.3 True rest and hybrid style

Usually developers do service-related client development, the use of so-called restful services, basically can be divided into 本真REST hybrid风格 two categories. The 本真REST restful architectural style that I elaborated above, with the above 4 characteristics, is the true sense of restful style, and hybrid风格 , just borrowed some of the advantages of restful, with a part of restful features, But outsiders still claim to be a restful style of service. (It is because the hybrid style service confuses the concept of restful that the concept of true rest is presented in a restful architectural style in order to divide the boundaries:P)

The most mainstream usage of the hybrid style is to use GET methods to obtain resources and to POST create, modify, and delete resources using methods. Hybrid style exists, as far as I know there are two sources: one is because some developers do not really understand what a restful architectural style, leading to the development of the service dubious, and the main reason is because of historical baggage-the service is originally RPC style, Due to the disadvantages of RPC and the advantages of restful, the developer has packaged a restful shell on the RPC-style service, usually the shell is only for resource service, so it will be implemented according to the restful style GET , if the client presents some simple creation, The requirements for modifying or deleting data are implemented using the most commonly used methods in the HTTP protocol POST .

Therefore, the development of restful services, if there is no historical burden, it is not recommended to use hybrid style.

2. Authentication mechanism

Because RESTful style services are stateless, authentication mechanisms are particularly important. For example, the employee's salary mentioned above, this should be a private resource, only the employee himself or a few other privileged people are eligible to see, if not through the authority authentication mechanism to make a layer of resources, then all resources are exposed, this is unreasonable, is also very dangerous.

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 licensed to use, modify, delete, or create resources. The authority mechanism is usually bound to the business logic of the service, so the permission mechanism needs to be customized within each system, and the authentication mechanism is basically universal, and the common authentication mechanism includes session auth (i.e. login by username password), basic auth token auth and OAuth , the authentication mechanism commonly used in service development is the latter three.

2.1 Basic Auth

HTTP Basic Authentication (BA) Implementation is the simplest technique for enforcing access controls to Web resources Bec Ause 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 has to B e done in anticipation.

Visit Wikipedia to Read more

In short, Basic auth is the simplest authentication method to use with RESTful APIs, with only a username and password, but because of the risk of exposing the username password to a third-party client, there is less use in the production environment. Therefore, when developing a restful API that is open to the outside, try to avoid using basic Auth

2.2 Token Auth

Token auth is not commonly used, and it differs from the basic auth in that it does not send the user name and password to the server for user authentication, but rather sends a token to the server that is generated in advance 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.

This article does not expand the introduction of token Auth, I personally have limited knowledge of this mechanism, interested in understanding the mechanism of the students may wish to start with this discussion on the stack overflow.

2.3 OAuth

OAuth is a 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 a authorization server, with the approval of the resource owner. The client then uses the access tokens to access the protected resources hosted by the resource server. OAuth is commonly used as a on-Internet users to log into third party websites using their Microsoft, Google, Faceboo K or Twitter accounts without exposing their password.

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

Visit Wikipedia to Read more

OAuth (Open Licensing) 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 a 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.

Now the online information about OAuth is very rich, there are a large number of open-source third-party libraries to implement the OAuth mechanism, not familiar with OAuth students from the OAuth official website to start.

3. Summary

• This true rest + OAuth is a standard for restful services
• Basic Auth is only used in the development environment
• Design a reasonable resource
• Send the correct request to the data with the correct HTTP method

RESTful Architectural Style Overview