What is rest-ful, and the realization of rest-ful

REST refers to a set of schema constraints and principles

• The most important REST principle of a WEB application is that the interaction between the client and the server is stateless between requests, and each request of the client must contain the information necessary to understand the request, and the server restarts at any point in time between requests and the client will not be notified Stateless requests can be answered by any available server and are ideal for environments such as cloud computing, where clients can cache data to improve performance.

• On the server side, application state and functionality can be categorized into various resources: each resource uses a URI (Universal Resource Identifier) to get a unique address. All resources share a unified interface to transfer state between the client and the server. Standard HTTP methods are used, such as GET, PUT, POST, and DELETE.

• Another important REST principle is layered systems: this means that a component cannot understand a component outside the middle tier it interacts with. By restricting system knowledge to a single layer, you can limit the complexity of the entire system and promote the underlying independence.

  When the constraints of the REST schema are applied as a whole, an application is generated that can be scaled to a large number of clients. It also reduces the interaction latency between the client and the server. The unified interface simplifies the entire system architecture and improves the visibility of interactions between subsystems. REST simplifies the implementation of clients and servers.

Rest-ful implementation: Building a multi-tiered architecture for RESTful WEB Services

RESTful Web Services and Dynamic Web applications are similar in many ways. Sometimes they provide the same or very similar data and functions, despite the different types of clients. For example, the online e-Commerce classification website provides users with a browser interface for searching, viewing, and ordering products. It is useful if you also provide WEB services for companies, retailers, and even individuals to automatically order products. As with most dynamic Web applications, Web services can benefit from the separation of concerns from multiple architectures. Business logic and data can be shared by automated clients and GUI clients. The only difference is the nature of the client and the presentation layer of the middle tier. In addition, separating business logic from data access enables database independence and provides plug-in capabilities for various types of data storage.

Figure 1 shows the Automation client, including scripts written in Java and in a variety of languages, including Python, Perl, Ruby, PHP, or command-line tools such as curl. Ajax, Flash, JavaFX, GWT, blogs, and wikis that run in the browser and run as a RESTful Web service consumer belong to this column because they all run in an automated style on behalf of the user. The Automation Web service client sends an HTTP response to the Resource Request Handler at the Web layer. The stateless request of the client contains method information in the header, that is, POST, GET, PUT, and DELETE, which in turn maps to the corresponding operation of the resource in the Resource request Handler. Each request contains all the necessary information, including the credentials that the Resource request Handler uses to process requests.

After receiving the request from the Web service client, Resource request Handler requests the service from the business logic layer. Resource Request Handler Identify all conceptual entities, which the system exposes as resources and assigns a unique URI to each resource. However, a conceptual entity does not exist at that level. They exist at the business logic layer. The Resource Request Handler can be implemented using Jersey or other frameworks (such as Restlet), which should be lightweight and delegate a lot of responsibility to the business layer.

Ajax and RESTful Web services are inherently complementary to each other. They can all take advantage of a number of WEB technologies and standards, such as HTML, JavaScript, browser objects, Xml/json, and HTTP. Of course, there is no need to purchase, install, or configure any major components to support the interaction between the Ajax front-end and RESTful Web services. RESTful Web Services provide Ajax with a very simple API to handle the interactions between resources on the server.

The Web browser client in Figure 1 serves as the front end of the GUI and provides display functionality using the HTML generated by the Browser Request Handler in the presentation layer. Browser requester Handler can use the MVC model (JSF, Struts, or Spring are examples of Java). It accepts requests from the browser, requests services from the business logic layer, generates representations, and responds to the browser. Represents the use that the user displays in the browser. Represents not only the content, but also the displayed properties, such as HTML and CSS.

Business rules can be centralized to the business logic layer, which acts as the middle tier for data exchange between the presentation layer and the data access layer. Data is provided to the presentation layer in the form of a domain object or a value object. Decoupling Browser request Handler and Resource request Handler from the business Logic layer helps facilitate code reuse and enables flexible and extensible architectures. In addition, because new REST and MVC frameworks can be used in the future, it becomes easier to implement them without rewriting the business logic layer.

The data access layer provides interaction with the data storage layer and can be implemented using DAO design patterns or object-relational mapping solutions such as Hibernate, OJB, or IBATIS. As an alternative, components in the business layer and data access layer can be implemented as EJB components and supported by the EJB container, which facilitates the component lifecycle and manages persistence, transaction, and resource configuration. However, this requires a Java EE-compliant application server (such as JBoss) and may not be able to handle Tomcat. The role of this layer is to separate the data access code from the business logic for different data storage technologies. The data access layer can also be used as an integration point to connect to other systems and can be a client for other WEB services.

Data storage tiers include database systems, LDAP servers, file systems, and enterprise information systems (including legacy systems, transaction processing systems, and enterprise resource planning systems). With this architecture, you can begin to see the power of RESTful Web Services, which provide the flexibility to become a unified API for any enterprise data store, exposing vertical data to user-centric Web applications and automating batch reporting scripts.

What is rest-ful, and the realization of rest-ful