Restful architecture style

In the tide of mobile Internet, the concept of “micro service” is more and more accepted and applied to practice. More and more web services are gradually unified in the restful architecture style. If the developers don’t know the restful architecture style, the so-called restful API developed will always be incongruous and not standardized.
Architecture style design:



  • 1. Restful architecture style
    • 1.1 characteristics of restful architecture style
      • 1.1.1 resources
      • 1.1.2 unified interface
      • 1.1.3 URI
      • 1.1.4 stateless
    • 1.2 ROA, SOA, rest and RPC
    • 1.3 authentic rest and hybrid style
  • 2. Authentication mechanism
    • 2.1 Basic Auth
    • 2.2 Token Auth
    • 2.3 OAuth

1. Restful architecture style

Restful architecture style was originally proposed by Roy T. Fielding (head of HTTP / 1.1 protocol expert group) in his doctoral dissertation in 2000. HTTP is a typical application of this architecture style. Since its birth, it has been favored by more and more architects and developers because of 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 services) has gradually surpassed soap as one of the important means to realize SOA. Today, restful architecture style has become the standard configuration of enterprise level services.

Rest is the abbreviation of representative state transfer, which can be translated as “representation layer state transfer”. The most important characteristics of rest are: resource, uniform interface, URI and stateless. Stateless requests that are specifically HTTP compliant.

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, it is a concrete reality. Resources always have to reflect their content through some 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.
Resources and data are understood as follows:

Resources are a set of user-oriented data sets with JSON (or other representation) as the carrier. The expression of resources to information tends to the data in the conceptual model:

  • Resources are always represented by a representation, that is, serialized information
  • The common representation is JSON (recommended) or XML (not recommended), etc
  • Representation is the presentation layer of rest architecture

Comparatively speaking, data (especially database) is a more abstract, more efficient and friendly data representation for computers, and more exists in logical models




1.1.2 unified interface

Restful architecture style stipulates that the meta operation of data, namely CRUD (create, read, update and delete, that is, add, delete, query and change of data), respectively corresponds to HTTP methods: get is used to obtain resources, post is used to create new resources (or update resources), put is used to update resources, and delete is used to delete resources, thus unifying the interface of data operation. Only through HTTP methods, it can It can complete all the work of adding, deleting, checking and modifying data.


  • Get (select): takes resources (one or more items) from the server.
  • Post (create): create a new resource on the server.
  • Put (update): update resources on the server (the client provides complete resource data).
  • Patch (update): update the resource on the server (the client provides the resource data to be modified).
  • Delete: deletes resources from the server.

1.1.3 URI

A URI (uniform resource locator) can be used to point to a resource, that is, each URI corresponds to a specific resource. To get this resource, you can access its URI, so the URI becomes the address or ID of each resource.

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

1.1.4 stateless

The so-called stateless, that is, all resources can be located by URI, and this location has nothing to do with other resources, and will not change due to the change of other resources. The difference between stateful and stateless is illustrated by a simple example. For example, to query the salary of an employee, if you need to log in to the system to enter the salary query page and perform related operations to obtain the salary, this situation isStatefulBecause every step of querying salary depends on the previous step. As long as the previous operation is not successful, the subsequent operation cannot be performed. If you enter a URL to get the salary of the specified employee, this situation isStatelessBecause obtaining salary does not depend on other resources or status, and in this case, employee salary is a resource corresponding to a URL, which can be obtained through theGETMethod, which is a typical restful style.




1.2 ROA, SOA, rest and RPC

ROAThat is, resource oriented architecture. Restful architecture style services focus onResourcesWhat is unfolded is a typical ROA architecture (although “a” and “architecture” are repeated, it doesn’t matter). Although ROA doesn’t conflict with SOA, or even consider ROA as a kind of SOA, RPC is also SOA, and a little papers, blogs or books have often discussed SOA and RPC together. Therefore, restful architecture style services are often called ROA architecture SOA architecture is rarely mentioned in order to distinguish it from RPC more explicitly.

RPC style was once the mainstream of Web services. At first, it was based on XML-RPC protocol (a distributed computing protocol of remote procedure call), and later it was gradually replaced by SOAP Protocol (Simple Object Access Protocol). RPC style services can not only useHTTP, you can also useTCPOr other communication protocol. However, RPC style services are greatly constrained by the language used for developing services. For example, in the. Net framework, the traditional way of developing web services is to use WCF. Services developed based on WCF are RPC style services. Clients using this service usually need to use C ා. If Python or other languages are used, it is difficult to directly communicate with the service clients; access to the mobile Internet After the era, RPC style services are difficult to use in mobile terminals, while restful style services can be directlyjsonorxmlTo carry the data for the carrier and complete the data operation with HTTP method as the unified interface, the development of the client does not depend on the technology of service implementation, and the mobile terminal can also easily use the service, which also intensifies that rest replaces RPC to become the dominant web service.

The differences between RPC and restful are shown in the following two figures:



1.3 authentic rest and hybrid style

Generally speaking, the so-called restful services that developers use when developing service related clients can be basically divided intoTrue RESTandHybrid styleThe two category.True RESTThat is, the restful architecture style I described above has the above four characteristics, which is the real sense of restful style; andHybrid styleIt only draws on some advantages of restful and has some characteristics of restful, but it still claims to be restful service. (I think it’s because the hybrid style service confuses the concept of restful that the concept of authentic rest is proposed in the restful architecture style, so as to divide the boundary: P)

The most popular use of the hybrid style is to useGETMethod, using thePOSTMethod to create, modify and delete resources. As far as I know, there are two sources for the existence of hybrid style: one is that some developers do not really understand what is restful architecture style, which leads to the seeming separation of developed services; the main reason is that the historical burden – services are originally RPC style, because of the disadvantages and advantages of RPC mentioned above, developers are in RPC style services Another layer of restful shell is wrapped. Generally, this layer is only for obtaining resource services, so it will be implemented in restful styleGETMethod, if the client requires some simple data creation, modification or deletion, the most commonly usedPOSTMethod.

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

2. Authentication mechanism




Because restful style services are stateless, authentication mechanism is particularly important. For example, the salary of employees mentioned above should be a private resource. Only the employees themselves or a few other people with permission are entitled to see it. If the resources are not limited through the authority authentication mechanism, then all resources are exposed in a public way, which 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 allowed to use, modify, delete or create the resource. The authority mechanism is usually bound to the business logic of the service, so the authority mechanism needs to be customized in each system, while the authentication mechanism is basically universal. The commonly used authentication mechanisms include session auth (login through user name and password), basic auth, token auth and OAuth. The commonly used authentication mechanisms in service development are the latter three.

2.1 Basic Auth
In short, basic auth is the simplest authentication method used with restful API, which only needs to provide user name and password. However, due to the risk of exposing user name and password to the third-party client, it is used less and less in the production environment. Therefore, basic auth should be avoided in the development of open restful API

2.2 Token Auth

Token auth is not commonly used. The difference between token auth and basic auth is that it does not send the user name and password to the server for user authentication, but sends a token generated on the server side in advance for authentication. Therefore, token auth requires the server to have a complete set of token creation and management mechanism. The implementation of this mechanism will increase a lot of unnecessary server-side development work, and it is not necessarily that this mechanism is safe and general enough, so token auth is not used much.

2.3 OAuth

OAuth (open authorization) is an open authorization standard, which allows the user to let the third-party application access the user’s private resources (such as photos, videos, contact lists) stored on a web service without providing the user name and password to the third-party application.

OAuth allows users to provide a token instead of a user name and password to access the data they store with a specific service provider. Each token authorizes a specific third-party system (e.g. video editing website) to access specific resources (e.g. only videos in an album) within a specific period of time (e.g. within the next 2 hours). In this way, OAuth allows users to authorize third-party websites to access certain information they store with other service providers, rather than all content.

If there is a problem with the way of authentication and login of OAuth, or there is a problem with the design of API interface, you can add group communication technology. At the same time, you can obtain the relevant TP5 \ laravel \ swoole source code