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.

Features of 1.1 RESTful architecture 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 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.

Based on my development practice, my understanding of resources and data is as follows:

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:

• Resources are always presented in the form of some Representation, that is, serialized information
• Common representations are JSON (recommended) or XML (not recommended)
• 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

Resource and data relationships are as follows:

1.1.2 Unified 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, and all data adding, deleting, checking, and modifying can be completed only through HTTP.

That is:

• GET (SELECT) : Retrieves one or more resources from the server.
• POST (CREATE) : Creates a resource on the server.
• PUT (UPDATE) : Updates resources on the server (the client provides complete resource data).
• PATCH (UPDATE) : updates resources on the server (the client provides the resource data to be modified).
• DELETE (DELETE) : deletes resources from the server.

1.1.3 URI

Resources can be pointed to by a URI (uniform resource Locator), meaning that each URI corresponds to a specific resource. To get the resource, access its URI, so the URI becomes the address or identifier for each resource.

Generally, each resource has at least one URI associated with it. The most typical URI is the URL.

1.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. A simple example illustrates the difference between stateless and stateful. 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 getting the salary does not depend on other resources or states, and in this case, the salary of an employee is a resource that corresponds to a URL and can be obtained through the GET method in HTTP, which is typically RESTful.

1.2 ROA, SOA, REST, and RPC

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 together in articles, blogs, and books a little longer, services with RESTful architecture are often referred to as ROA architecture and SOA architecture is rarely mentioned in order to be more explicitly distinguished from RPC.

RPC style was once the mainstream of Web services, originally based on XML-RPC (a remote Procedure Call (RPC) distributed computing protocol), It was gradually replaced by SOAP (Simple Object Access Protocol). Rpc-style services can be used not only with HTTP, but also with TCP or other communication protocols. However, RPC-style services are more constrained by the language used to develop services, such as. NET framework, the traditional way to develop web service is to use WCF, based on the WCF development service is RPC style service, the client using the service is usually implemented in C#, if using python or other languages, it is difficult to achieve the client can directly communicate with 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, This has contributed to REST replacing RPC as 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, the so-called RESTful services used by developers for service-related client development can be basically divided into two types: native REST and hybrid. True REST is the RESTful architectural style I described above. It has the four characteristics mentioned above and is truly RESTful. Hybrid style, however, only draws on some advantages of RESTful and has some features of RESTful, but it still claims to be a RESTful service externally. (It is assumed that hybrid services confuse RESTful concepts and introduce the concept of authentic REST in RESTful architectural styles to draw boundaries :P)

The most popular use of the Hybrid style is to use the GET method to GET resources and the POST method to create, modify, and delete resources. The hybrid style exists, as FAR as I know, in two ways: one is because some developers don’t really understand what a RESTful architectural style is, resulting in the development of services that don’t fit together; The mainstream reason is due to the historical burden — the service was originally rPC-style. Due to the disadvantages and RESTful advantages of RPC mentioned above, developers put a RESTful shell on the RPC-style service. Usually, this shell is only for obtaining resource services, so they implement GET method in a RESTful style. If the client proposes some simple requirements to create, modify or delete data, it realizes the corresponding functions through the POST method, which is most commonly used in HTTP protocol.

Therefore, the hybrid style is not recommended for developing RESTful services without historical baggage.

2. Authentication mechanism

Because RESTful services are stateless, authentication is especially important. For example, the employee salary mentioned above should be a private resource, and only the employee himself or a few other people with authority are qualified to see it. If the resource is not restricted through the authority authentication mechanism, then all the resources are exposed in a public way, which is unreasonable and dangerous.

The authentication mechanism solves the problem of determining the user who accesses the resource; The permission mechanism addresses the problem of determining whether a user is allowed to use, modify, delete, or create a resource. The permission mechanism is usually bound to the service logic, so the permission mechanism needs to be customized within each system. However, the authentication mechanism is basically universal. Commonly used authentication mechanisms include Session Auth (login by user name and password), Basic Auth, Token Auth and OAuth. Authentication mechanisms commonly used in service development 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 use with RESTful apis, requiring only a username and password, but it is used less and less in production environments due to the risk of exposing the username and password to third-party clients. Therefore, when developing RESTful apis that are open to the outside world, try to avoid using Basic Auth

2.2 Token Auth

Token Auth is not commonly used. It differs from Basic Auth in that the user name and password are not sent to the server for user authentication. Instead, a Token generated on the server is sent to the server for authentication. Therefore, Token Auth requires the server side to have a complete set of Token creation and management mechanism. The implementation of this mechanism will add a lot of unnecessary server-side development work, and this mechanism may not be safe and general enough, so Token Auth is not used much.

This article is not going to introduce Token Auth. I personally have limited understanding of this mechanism. If you are interested in understanding this mechanism, you may wish to start with this discussion on Stack Overflow.

2.3 request

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 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.

At present, the information about OAuth on the Internet is very rich, there are also a large number of open source third-party libraries to achieve OAuth mechanism, students who are not familiar with OAuth can start from the official website of OAuth.

3. Summary

• True REST + OAuth RESTful is the standard configuration of microservices
• Basic Auth is only used in development environments
• Well-designed resources
• Make the right request for the data using the right HTTP method

Further reading: RESTful API writing guide