第11章Webアプリケーション開発

Understanding APIs and their protocols helps determine which platform is being accessed and at what level. APIs allow access to any software with a specific purpose or functionality. APIs can be used as contracts between multiple applications.

How do APIs work? The API architecture is usually explained in terms of client and server. The application sending the request is called the client, and the application sending the response is called the server. For example, in the case of an API for a weather service, the weather service database is maintained on the server side, and the mobile app is running on a client mobile device.

The server side performs the majority of the functionality. It uses a combination of templated HTML, controller and application server technologies (e.g., ASP.NET, C#), and SQL. JavaScript is sent to the browser using jQuery for cross-browser support, or it may use Asynchronous JavaScript and XML to communicate with the web server without refreshing the page. Asynchronous JavaScript and XML (AJAX) exchanges small amounts of data between a client and server. The engineering team using such a web platform must understand and enforce the separation of responsibilities between the MVC components to ensure future modifications, especially significant changes, can be made without rearchitecting the system. Because the engineering team needs to know different programming languages for different layers, there may be some internal resistance to this, and it may be tempting to go around a layer to make a quick fix. Essentially, making sure that the architecture of the web platform is understood and used properly, architectural adherence is predicated on the expertise of the engineering team members and more on the nature of the tools used.

By the mid-2000s, JavaScript became popular for client-side browser functionality. AJAX and jQuery technologies allowed developers to create single-page applications (SPA). For the end user, SPAs offered functionality like a traditional desktop application and drastically improved user experience by reducing latency. No longer were expensive web server requests needed that resulted in full page refreshes in the browser. Instead, small data transmissions could be sent and received between the browser and server through AJAX. Figure 11.5 compares the life cycle of SPAs to a traditional Web 2.0 application.

The World Wide Web Consortium (W3C) (https://openstax.org/r/76W3C) develops standards and guidelines for the Web. You can discover more about them and examine some of their current draft standards.

jQuery, an open-source JavaScript library, ensured that web developers could write JavaScript for a generic browser document object model (DOM) that would run regardless of the user’s browser. The DOM is a programming interface provided by browsers. It allows scripts, written in JavaScript for example, to interact with the structure of a web page. When a web page is loaded into the browser, the browser creates a DOM of the page. The DOM structure is a hierarchical treelike structure that organizes the elements of the page as objects. The model used by the DOM enables dynamic access and facilitates the manipulation of content, structure, and style of web pages. Figure 11.6 illustrates a typical SPA architecture where a single web page is delivered to the browser. Note that in this model, the user’s interaction with the site has increased in the amount of content generated by the user.

The more sophisticated SPAs required large amounts of JavaScript on the client side. Many end users had underpowered machines or out-of-date web browsers, and the SPAs performed poorly.

In the early 2010s, web application frameworks were introduced to create complex, client-side web applications that performed well, gave a native desktop application-like experience, and were easier for developers to create. These applications followed a Model-View-ViewModel (MVVM) pattern. Figure 11.7 illustrates the relationship between the View, ViewModel, and Model components.

This pattern is like the MVC pattern we’ve previously explored; however, several key differences exist. The following are some of the similarities and differences:

• The View is responsible for the presentation and only interacts with the ViewModel. This is similar in responsibility to the View role and interaction with the Controller in the MVC pattern. The View here binds to functions and properties in the ViewModel and receives notifications on operations and changes to the data. It doesn’t interact directly with the Model.

• The Model is similar to the Model in the MVC pattern and is responsible for data retrieval and storage. It doesn’t know anything about the ViewModel.

• The ViewModel is similar to the Controller in that it decouples the relationship between the View and Model and handles data manipulation. The ViewModel responds to notifications from the Model and will send events to the View if needed. Because the View binds to the ViewModel, the ViewModel doesn’t know anything about the View. The ViewModel can work with a local Model in the browser, a remote Model, or both.

Unlike the previous MVC pattern regarding server-side rendering, the MVVM pattern is run entirely in the client. A Representational State Transfer (REST) API decouples the client-side Model and ViewModel components from the server-side business logic and persistence store. REST-based (aka RESTful) APIs follow the architecture style designed for the Web. These APIs use the JavaScript Object Notation (JSON) file format that represents data as text-based attribute-value information. Figure 11.8 illustrates the MVVM pattern as it applies to an SPA.

As you can see from the diagram, this model is more complex than the simpler MVC pattern. The quality of the APIs partly determines the effectiveness of this pattern. REST-based APIs benefit from being discoverable (i.e., all API URIs can be found from the root API node) and should be versioned (i.e., to keep track of changes to interfaces for compatibility purposes) so that upgrades don’t break API users. Without API versioning, coupling between client and server increases (due to semantic and syntactic coupling), and upgrades become costly. Similar to a URL, a Uniform Resource Identifier (URI) is a string of characters that identifies a resource on the Web.

Regardless of these flaws, early browser-based frameworks proved the value of creating rich client-side apps. Web standards evolved, and newer frameworks emerged that adhered to the newer standards and solved many of the problems of their predecessors. Popular SPA frameworks include Angular, Ember.js, React, and Vue.js. These are often used in conjunction with server-side tools, creating a “full stack” of technologies for developing the solution. A popular server-side technology in this stack is Node, a runtime environment for executing JavaScript code.

Approaches to minimizing the data transferred between the APIs and the client to reduce network traffic or simplifying access to the data resulted in two primary approaches. One was flattening the data model. Instead of returning data in a nested format (such as from a relational database), the returned data would be “flattened” to a series of key-value pairs, each resulting in a unique return value. If the specific request could be made, the flattened data would be preferred to navigating the nested data to improve performance. However, creating APIs to fit specific requests could be challenging. Another solution was using GraphQL, an open-source query and manipulation language. With GraphQL, callers of its API could craft specific requests to return only the needed data, which made access to many services such as the ones provided by microservices architectures more scalable.