Combining Ajax and REST frameworks makes Web applications more advantageous (1)

Because of the rich application model and personalized content delivery, Web applications on the server end have the immersive feature, application Architecture violates the Web architecture REST (Representational State Transfer) more. This violation will reduce the scalability of the application and increase the complexity of the system. Through coordination with REST, the Ajax architecture will eliminate these negative effects for integrated Web applications and enjoy the outstanding features of REST.

In just 15 years, World Wide Web has grown from a research experiment to a technical pillar of modern society. The purpose of the Web was originally invented to enable people to easily publish and link information, and now it has evolved into a viable platform for software applications. However, as applications get more integration by using rich Application Models and generating personalized content, their architecture has a restful Web architecture style (Representational State Transfer) more and more violations. This violation will reduce the scalability of the application and increase the complexity of the system.

The emerging Ajax Web client architecture style makes the integrated Web applications consistent with the REST architecture style. So that they can enjoy the excellent features of REST, while eliminating the bad features of applications that violate the REST rules. This article describes how to integrate Ajax and REST into a Web application.

REST: Web architecture

Although World Wide Web was established on the basis of decades of research, its effective date was December 1990, when Tim Berners-Lee completed the prototype of the main Web components: unified Resource Identifier (URI), HTTP, HTML, browser, and server. The rapid adoption of Web far exceeds the expectations of pioneers. Roy Fielding described his mood in the most famous series:

"Despite being excited about its success, the Internet developer community is gradually worried about the rapid growth in Web Usage and some poor network features of early HTTP, will quickly overwhelm the capacity that the Internet infrastructure can undertake, resulting in a sudden collapse."

Fielding and others reviewed the Web architecture and whether it could support various extensions and usage. The tangible results of this review include updating important standards such as URI and HTTP. This review also produces some intangible but very meaningful results: a new architecture style is defined for super media applications, fielding named it REST (Representational State Transfer ). Fielding asserted that components deployed on the Web that meet the REST design constraints can fully utilize the useful features of the Web. He also warned that Web Components that violate the REST rules would not be able to take advantage of these advantages.

In the early days, most Web sites and simple Web applications actually followed the REST rules. However, with the increasing popularity of integrated Web applications, the Web application architecture has gradually deviated from the REST rules, followed by a causal cycle, and the situation has deteriorated. It is difficult to analyze the problem of Integrated server-side Web architecture because the following belief has been established over the past decade: these problems are inherent in the Web application architecture. In fact, this is not a problem with the Web application architecture. It is caused by the architecture style of the Web application on the server side. To break this prejudice, let's review how the entire architecture has evolved to the present state, which will be very helpful. We will explain why many assumptions accepted in the past are no longer valid after Ajax applications are created commercially available.

A Brief History of Web Applications

Berners-Lee created the Web, which was initially a means for researchers to remotely share documents and create simple links between documents to accelerate the spread of knowledge and ideas. However, the architecture features of the URI standard quickly enable more content sharing besides static files.

Websites that provide static documents

The earliest content on the Web is composed of some static HTML documents. There are many links to other static documents, as shown in 1:

Figure 1. Web site that provides static documents

REST makes the retrieval of static documents extremely efficient and scalable, because they can be easily cached Based on the URI and the last modification date. Soon, developers surpassed the field of static documents and began to provide dynamic documents.

Early Dynamic Web Applications

Berners-Lee and others have designed URI standards to provide support for uniform and unique resource identifiers and make their representation (HTML, text, etc.) based on Web clients (usually Web browsers) and the Web server. Because URI separates the Resource Identifier from the underlying storage mechanism of the resource, Web developers can create programs to check the URI syntax and generate documents dynamically, combine predefined UI elements with dynamically retrieved data (usually from relational databases), as shown in figure 2. Although these documents are generated, their cache features are exactly the same as those of static files.

Figure 2. Web sites that provide database records in the form of embedded HTML template code

A simple example of such early applications is to unify the directory of Web applications. This type of application usually works as follows:

1. In the Web form, enter the name, for example, Bill Higgins, and click Submit.
2. The form creates a URI based on the input name and requests the contents of this URI from the server, for example, GET http://psu.edu/Directory/Bill+Higgins ).
3. The server checks the URI and uses the student's phone number and address to generate a Web page.
4. The server sends the generated page back to the user's browser.

An important feature of this interaction is the idempotent), that is, unless the underlying resources change, such as Bill modifies his phone number), the results of the same request will always be the same. This means that both the browser and the proxy server can cache the Bill Higgins documentation locally. as long as the underlying resources do not change, the resources can be retrieved from the local cache, instead of retrieval from a remote server. This method can improve the user's responsiveness and increase the overall efficiency and scalability of the system. These early Dynamic Web applications can work well and send a large amount of information to the user's fingertips.

Integrated Web Applications

The goal of the next generation of Web applications is to be highly integrated to provide personalized content and rich application models. Over the past decade, Web developers have successfully created these integrated applications. A very appropriate example is the Amazon.com e-commerce site. When a user interacts with an Amazon Web application, it creates a complex customer page to recommend targeted products, display browsing history, and display the prices of products in the user's shopping cart.

Integrated server applications and REST

Integrated Web applications are indeed very useful, but the server-side integrated Web application style is fundamentally not in line with the REST architecture principles. Specifically, it violates a key REST constraint and does not take advantage of some of the most important advantages of REST. Therefore, it creates a new set of problems.

Violating the "stateless server" Constraint

The "client-stateless-server" constraint of REST prohibits you from saving the session status on the server. Designing with this constraint improves system visibility, reliability, and scalability. However, the integrated server-side Web application needs to provide a large amount of personalized content for a single user, so you must choose between the two designs. The first design requires that a large amount of status information be sent in each client request. Therefore, each request completely retains the context content, and the server is stateless. The second solution is relatively simple on the surface. application developers and middleware vendors prefer this method. It simply sends a user ID, and associate a "user session" 3 for this identifier on the server side ). The second design directly violates the client-stateless-server constraints. Although it can indeed implement the user features we want specifically, it refers to personalization), but it has made great changes to this architecture.

Figure 3. Integrated server-side Web applications, including a large number of server-side session states

Java™Servlet's HttpSession API is an example of such changes. HttpSession allows us to establish associations between statuses and specific users. This API seems very simple for new developers. In fact, it seems that any object can be saved to HttpSession, and these objects can be retrieved without any specific search logic. However, when we start to add more objects to HttpSession, we will begin to notice that our application servers are occupying more and more memory and processing resources. Soon, we decided we needed to deploy the application to the cluster environment to meet the increasing resource demands. Then we will realize that to enable HttpSession to work in the Cluster Environment, each object must implement the Java Serializable interface so that session data can be transmitted between servers in the cluster environment. Then, you must determine whether the application server will continue to maintain session data during Shutdown/restart. Soon you will question whether it is a good idea to violate the client-stateless-server constraints. In fact, many developers do not understand this constraint .)