summarize

REST is an acronym for Representational State Transfer, which translates to "Representational State Transfer" in Chinese, and is an architectural style for developing Web services. REST is popular because of its simplicity and the fact that it builds on existing systems and features of the Internet's Hypertext Transfer Protocol (HTTP) to achieve its goals, rather than creating new standards, frameworks, and technologies. client-server message exchanges, but rather insists that the best way to implement Web-based Web services is to use thenetwork protocolThe basic structure of itself, as far as the Internet is concerned, is HTTP.

Advantages of using REST

• One of the main benefits of using REST from both the client and server perspectives is that REST interactions are based on constructs familiar to anyone accustomed to using HTTP.REST takes a resource-based approach that defines the way developers interact with Web services.
• REST-based interactions communicate their status through numeric HTTP status codes, which are used by REST APIs to detect errors and simplify API monitoring.
• Most developers are already familiar with the key elements of the REST architecture, such as SSL, TLS, and other security and encryption protocols.
• When creating RESTful APIs or Web services, developers can use any language that uses HTTP to make Web-based requests. This feature makes it easy for programmers to choose the technology they prefer to use and that best suits their needs.
• The popularity of REST is due to its widespread use in both server-side and client-side implementations. For example, on the server side, developers can use REST-based frameworks including Restlet and Apache CXF. On the client side, developers can use a variety of frameworks (i.e., jQuery, Node.js, Angular, EmberJS, etc.) and invoke RESTful Web services using standard libraries built into their APIs.
• In terms of caching, RESTful services utilize efficient HTTP mechanisms. For example, by providing a number of endpoints, the REST API makes it easier for developers to create complex queries that can be tailored to meet the needs of a particular deployment.

Development History

The Web came into everyday use in 1993-1994, when general-purpose Web sites became available, and at that time, there were only fragmentary descriptions of the Web architecture, and the industry was under pressure to agree on a number of standards for Web interface protocols. For example, several experimental extensions were added to the communications protocol (HTTP) to support proxies, and more extensions were being proposed, but a formal Web architecture was needed to evaluate the impact of these changes

Together, the W3C and IETF working groups set out to create formal descriptions of the Web's three main standards: URIs, HTTP, and HTML. Roy Fielding was involved in the creation of these standards (specifically HTTP 1.0 and 1.1, and URIs), and over the next six years he developed the REST architectural style, testing its constraints on Web protocol standards and using it as a means of defining architectural improvements - and identifying architectural mismatches. and used it as a means of defining architectural improvements - and identifying architectural mismatches.

In 2000, Fielding defined REST in his doctoral dissertation, "Architectural Styles and the Design of Web-Based Software Architectures," at the University of California, Irvine, identifying the requirements that apply when creating Web-based applications of global scope, such as the need for low barriers to entry to achieve global adoption.

protocol standard

Architecture Concepts

The REST architecture style is designed for web-based applications (especially client-server applications). But more importantly, it is designed for Internet-scale use, so the user agent user agent (client) and the source server origin serverThe coupling between them must be as lightweight (loose) as possible to facilitate mass adoption. This is achieved by creating an abstraction layer on the server by defining resources that encapsulate entity entities (e.g. files) on the server resourcesThis hides the underlying implementation details (file servers, databases, etc.). But the definition is even more general than that: any information that can be named can be a resource: an image, a database query, a time service (e.g., "today's weather in London"), or even a collection of other resources. This approach allows for maximum interoperability between clients and servers in long-term Internet-scale environments that cross organizational (trust) boundaries.

Clients can only access resources using URIs. In other words, the client requests a resource using a URI, and the server responds using a representation of the resource. The representation of a resource is another important concept in REST; to ensure that the response can be interpreted by as many client applications as possible, a representation of the resource is sent in hypertext format, and the resource is manipulated by the hypertext representation transmitted in messages between the client and the server.

Architectural Properties

• performance in component interactions, which can be a dominant factor in user-perceived performance and network efficiency; the
• Scalability allows support for a large number of components and interactions between components; the
• Simplicity of the harmonized interface.
• Modifiability of components to meet changing needs (even while the application is running); and
• Visibility of service proxies into inter-component communication; the
• Portability of components by moving program code and data.
• Reliability against failure at the system level in the event of a failure in a component, connector or data

Architecture Specification

The REST architecture style defines six guiding specifications. When these specifications are applied to a system architecture, it acquires desirable non-functional properties such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability. Systems that conform to some or all of these specifications are loosely referred to as RESTful.

client-server architecture

By separating user interface concerns from data storage concerns, user interface portability is improved. This proposed specification improves the portability of the user interface across multiple platforms and improves the scalability of the system by simplifying the server components. Most critically, by separating the user interface and data storage concerns, it is possible to enjoy the same data across different user terminals.

Statelessness:

That is, each request from the client to the server must contain all the information necessary to understand the request. This specification improves system visibility (statelessness eliminates the need for the client and server to save each other's details; the server only needs to process the current request and does not need to know the history of all requests), reliability (statelessness reduces the server's task of recovering from localized errors), and scalability (statelessness makes it easy for the server to release resources, since the server does not have to save state across multiple requests). (statelessness makes it easy to release resources on the server side, since the server side doesn't have to keep state in multiple requests). Of course there is also a waste of resources due to the lack of contextual support.

unified interface

The Unified Interface is the foundation of any RESTful system design. It simplifies and decouples the architecture, allowing each part to evolve independently. The four specifications of this unified interface are:

• Resource Identification in Requests - identifies a single resource in a request, for example, using a URI in a RESTful Web service
• Resource manipulation by representation
• Self-descriptive messages - each message contains enough information to describe how to process the message
• After accessing the initial URI of the REST application (similar to a human Web user accessing the home page of a Web site), the REST client should be able to dynamically use the links provided by the server to discover all the available resources it requires

cacheability

Clients and intermediaries can cache responses. Responses must implicitly or explicitly define themselves as cacheable or non-cacheable to prevent clients from providing outdated or inappropriate data in response to further requests. A well-managed cache can partially or completely eliminate some client-server interactions, further improving scalability and performance. Caching can be performed in the client computer's memory or in the browser's cache store

hierarchical system

A client usually cannot tell whether it is connecting directly to a terminal server or to an intermediate server. If a proxy or load balancer is placed between the client and the server, it does not affect their communication and does not require updates to the client or server code. Intermediate servers can improve system scalability by enabling load balancing and providing shared caching

on-demand coding

REST allows for the extension of client-side functionality. For example, client-side functionality can be extended by downloading and executing code in the form of applets or scripts. But this improves system scalability while reducing visibility. So it is only an optional constraint of REST

operating resource

For how to manipulate resources, there are corresponding HTTP verbs that correspond to the following five common verbs (the SQL equivalent commands are indicated in parentheses):

GET (SELECT): take resources (one or more) from the server
POST (CREATE): create a new resource on the server
PUT (UPDATE): update the resource at the server (the client provides the full resource after changes)
PATCH (UPDATE): update the resource at the server (client provides changed attributes)
DELETE (DELETE): Delete resources from the server