Preparing the Example Project

This chapter uses the exampleApp project created in Chapter 22. For this chapter, I rely on a server that responds to HTTP requests with JSON data. Run the command shown in Listing 24-1 in the exampleApp folder to add the json-server package to the project.

Running the Example Project

Open a new command prompt, navigate to the exampleApp folder, and run the following command to start the data server:

npm run json

This command will start the json-server, which will listen for HTTP requests on port 3500. Open a new browser window and navigate to http://localhost:3500/products/2. The server will respond with the following data:

{ "id": 2, "name": "Lifejacket", "category": "Watersports", "price": 48.95 }

Leave the json-server running and use a separate command prompt to start the Angular development tools by running the following command in the exampleApp folder:

ng serve

Use the browser to navigate to http://localhost:4200 to see the content illustrated in Figure 24-1.

Understanding RESTful Web Services

The most common approach for delivering data to an application is to use the Representational State Transfer pattern, known as REST, to create a data web service. There is no detailed specification for REST, which leads to a lot of different approaches that fall under the RESTful banner. There are, however, some unifying ideas that are useful in web application development.

The core premise of a RESTful web service is to embrace the characteristics of HTTP so that request methods—also known as verbs—specify an operation for the server to perform, and the request URL specifies one or more data objects to which the operation will be applied.

The first segment of the URL—products—is used to indicate the collection of objects that will be operated on and allows a single server to provide multiple services, each of which with its own data. The second segment—2—selects an individual object within the products collection. In the example, it is the value of the id property that uniquely identifies an object and that will be used in the URL, in this case, specifying the Lifejacket object.

The HTTP verb or method used to make the request tells the RESTful server what operation should be performed on the specified object. When you tested the RESTful server in the previous section, the browser sent an HTTP GET request, which the server interprets as an instruction to retrieve the specified object and send it to the client. It is for this reason that the browser displayed a JSON representation of the Lifejacket object.

Caution is required because there can be considerable differences in the way that some RESTful web services work, caused by differences in the frameworks used to create them and the preferences of the development team. It is important to confirm how a web service uses verbs and what is required in the URL and request body to perform operations.

Some common variations include web services that won’t accept any request bodies that contain id values (to ensure they are generated uniquely by the server’s data store) or any web services that don’t support all of the verbs (it is common to ignore PATCH requests and only accept updates using the PUT verb).

Replacing the Static Data Source

The best place to start with HTTP requests is to replace the static data source in the example application with one that retrieves data from the RESTful web service. This will provide a foundation for describing how Angular supports HTTP requests and how they can be integrated into an application.

Using the REST Data Source

The final step is to update the repository class so that it declares a dependency on the new data source and uses it to get the application data, as shown in Listing 24-8.

import { Injectable } from "@angular/core";

import { Product } from "./product.model";

//import { StaticDataSource } from "./static.datasource";

import { Observable } from "rxjs";

import { RestDataSource } from "./rest.datasource";

@Injectable()

export class Model {

    private products: Product[] = new Array<Product>();

    private locator = (p: Product, id: number) => p.id == id;

    constructor(private dataSource: RestDataSource) {

        //this.products = new Array<Product>();

        //this.dataSource.getData().forEach(p => this.products.push(p));

        this.dataSource.getData().subscribe(data => this.products = data);

    }

    getProducts(): Product[] {

        return this.products;

    }

    getProduct(id: number): Product {

        return this.products.find(p => this.locator(p, id));

    }

    saveProduct(product: Product) {

        if (product.id == 0 || product.id == null) {

            product.id = this.generateID();

            this.products.push(product);

        } else {

            let index = this.products

                .findIndex(p => this.locator(p, product.id));

            this.products.splice(index, 1, product);

        }

    }

    deleteProduct(id: number) {

        let index = this.products.findIndex(p => this.locator(p, id));

        if (index > -1) {

            this.products.splice(index, 1);

        }

    }

    private generateID(): number {

        let candidate = 100;

        while (this.getProduct(candidate) != null) {

            candidate++;

        }

        return candidate;

    }

}

Listing 24-8.

Using the New Data Source in the repository.model.ts File in the src/app/model Folder

The constructor dependency has changed so that the repository will receive a RestDataSource object when it is created. Within the constructor, the data source’s getData method is called, and the subscribe method is used to receive the data objects that are returned from the server and process them.

When you save the changes, the browser will reload the application, and the new data source will be used. An asynchronous HTTP request will be sent to the RESTful web service, which will return the larger set of data objects shown in Figure 24-2.

Saving and Deleting Data

The data source is able to get data from the server, but it also needs to send data the other way, persisting changes that the user makes to objects in the model and storing new objects that are created. Listing 24-9 adds methods to the data source class to send HTTP requests to save or update objects using the Angular HttpClient class.

import { Injectable, Inject, InjectionToken } from "@angular/core";

import { HttpClient } from "@angular/common/http";

import { Observable } from "rxjs";

import { Product } from "./product.model";

export const REST_URL = new InjectionToken("rest_url");

@Injectable()

export class RestDataSource {

    constructor(private http: HttpClient,

        @Inject(REST_URL) private url: string) { }

    getData(): Observable<Product[]> {

        return this.http.get<Product[]>(this.url);

    }

    saveProduct(product: Product): Observable<Product> {

        return this.http.post<Product>(this.url, product);

    }

    updateProduct(product: Product): Observable<Product> {

        return this.http.put<Product>(`${this.url}/${product.id}`, product);

    }

    deleteProduct(id: number): Observable<Product> {

        return this.http.delete<Product>(`${this.url}/${id}`);

    }

}

Listing 24-9.

Sending Data in the rest.datasource.ts File in the src/app/model Folder

The saveProduct, updateProduct, and deleteProduct methods follow the same pattern: they call one of the HttpClient class methods and return an Observable<Product> as the result.

When saving a new object, the ID of the object is generated by the server so that it is unique and clients don’t inadvertently use the same ID for different objects. In this situation, the POST method is used, and the request is sent to the /products URL. When updating or deleting an existing object, the ID is already known, and a PUT request is sent to a URL that includes the ID. So, a request to update the object whose ID is 2, for example, is sent to the /products/2 URL. Similarly, to remove that object, a DELETE request would be sent to the same URL.

What these methods have in common is that the server is the authoritative data store, and the response from the server contains the official version of the object that has been saved by the server. It is this object that is returned as the result from these methods, provided through the Observable<Product>.

Listing 24-10 shows the corresponding changes in the repository class that take advantage of the new data source features.

import { Injectable } from "@angular/core";

import { Product } from "./product.model";

import { Observable } from "rxjs";

import { RestDataSource } from "./rest.datasource";

@Injectable()

export class Model {

    private products: Product[] = new Array<Product>();

    private locator = (p: Product, id: number) => p.id == id;

    constructor(private dataSource: RestDataSource) {

        this.dataSource.getData().subscribe(data => this.products = data);

    }

    getProducts(): Product[] {

        return this.products;

    }

    getProduct(id: number): Product {

        return this.products.find(p => this.locator(p, id));

    }

    saveProduct(product: Product) {

        if (product.id == 0 || product.id == null) {

            this.dataSource.saveProduct(product)

                .subscribe(p => this.products.push(p));

        } else {

            this.dataSource.updateProduct(product).subscribe(p => {

                let index = this.products

                    .findIndex(item => this.locator(item, p.id));

                this.products.splice(index, 1, p);

            });

        }

    }

    deleteProduct(id: number) {

        this.dataSource.deleteProduct(id).subscribe(() => {

            let index = this.products.findIndex(p => this.locator(p, id));

            if (index > -1) {

                this.products.splice(index, 1);

            }

        });

    }

}

Listing 24-10.

Using the Data Source Features in the repository.model.ts File in the src/app/model Folder

The changes use the data source to send updates to the server and use the results to update the locally stored data so that it is displayed by the rest of the application. To test the changes, click the Edit button for the Kayak product and change its name to Green Kayak. Click the Save button, and the browser will send an HTTP PUT request to the server, which will return a modified object that is added to the repository’s products array and is displayed in the table, as shown in Figure 24-3.

You can check that the server has stored the changes by using the browser to request http://localhost:3500/products/1, which will produce the following representation of the object:

{

  "id": 1,

  "name": "Green Kayak",

  "category": "Watersports",

  "price": 275

}

Consolidating HTTP Requests

Each of the methods in the data source class duplicates the same basic pattern of sending an HTTP request using a verb-specific HttpClient method. This means that any change to the way that HTTP requests are made has to be repeated in four different places, ensuring that the requests that use the GET, POST, PUT, and DELETE verbs are all correctly updated and performed consistently.

The request method accepts the HTTP verb, the URL for the request, and an optional object that is used to configure the request. The configuration object is used to set the request body using the body property, and the HttpClient will automatically take care of encoding the body object and including a serialized representation of it in the request.

Making Cross-Origin Requests

By default, browsers enforce a security policy that allows JavaScript code to make asynchronous HTTP requests only within the same origin as the document that contains them. This policy is intended to reduce the risk of cross-site scripting (CSS) attacks, where the browser is tricked into executing malicious code. The details of this attack are beyond the scope of this book, but the article available at http://en.wikipedia.org/wiki/Cross-site_scripting provides a good introduction to the topic.

As the table shows, the URL for the RESTful web service, http://localhost:3500/products, has a different origin because it uses a different port from the main application.

HTTP requests made using the Angular HttpClient class will automatically use Cross-Origin Resource Sharing to send requests to different origins. With CORS, the browser includes headers in the asynchronous HTTP request that provide the server with the origin of the JavaScript code. The response from the server includes headers that tell the browser whether it is willing to accept the request. The details of CORS are outside the scope of this book, but there is an introduction to the topic at https://en.wikipedia.org/wiki/Cross-origin_resource_sharing, and the CORS specification is available at www.w3.org/TR/cors.

For the Angular developer, CORS is something that is taken care of automatically, just as long as the server that receives asynchronous HTTP requests supports the specification. The json-server package that has been providing the RESTful web service for the examples supports CORS and will accept requests from any origin, which is why the examples have been working. If you want to see CORS in action, use the browser’s F12 developer tools to watch the network requests that are made when you edit or create a product. You may see a request made using the OPTIONS verb, known as the preflight request, which the browser uses to check that it is allowed to make the POST or PUT request to the server. This request and the subsequent request that sends the data to the server will contain an Origin header, and the response will contain one or more Access-Control-Allow headers, through which the server sets out what it is willing to accept from the client.

All of this happens automatically, and the only configuration option is the withCredentials property that was described in Table 24-5. When this property is true, the browser will include authentication cookies, and headers from the origin will be included in the request to the server.

Configuring Request Headers

Handling Errors

Improving this situation means detecting this kind of error when one occurs and notifying the user, who won’t typically be looking at the JavaScript console. A real application might also respond to errors by logging them so they can be analyzed later, but I am going to keep things simple and just display an error message.

Handling the Errors

The errors have been transformed but not handled, which is why they are still being reported as exceptions in the browser’s JavaScript console. There are two ways in which the errors can be handled. The first is to provide an error-handling function to the subscribe method for the Observable objects created by the HttpClient object. This is a useful way to localize the error and provide the repository with the opportunity to retry the operation or try to recover in some other way.

The second approach is to replace the built-in Angular error-handling feature, which responds to any unhandled errors in the application and, by default, writes them to the console. It is this feature that writes out the messages shown in the previous sections.

For the example application, I want to override the default error handler with one that uses the message service. I created a file called errorHandler.ts in the src/app/messages folder and used it to define the class shown in Listing 24-18.

import { ErrorHandler, Injectable, NgZone } from "@angular/core";

import { MessageService } from "./message.service";

import { Message } from "./message.model";

@Injectable()

export class MessageErrorHandler implements ErrorHandler {

    constructor(private messageService: MessageService, private ngZone: NgZone) {

    }

    handleError(error) {

        let msg = error instanceof Error ? error.message : error.toString();

        this.ngZone.run(() => this.messageService

            .reportMessage(new Message(msg, true)), 0);

    }

}

Listing 24-18.

The Contents of the errorHandler.ts File in the src/app/messages Folder

The ErrorHandler class is defined in the @angular/core module and responds to errors through a handleError method. The class shown in the listing replaces the default implementation of this method with one that uses the MessageService to report an error.

The constructor receives an ngZone object, which is part of the Angular support for asynchronous operations and is an essential part of the change detection feature. In this listing, the ngZone object’s run method is used to report an error message so that the operation will trigger the change detection process and display the error to the user.

To replace the default ErrorHandler, I used a class provider in the message module, as shown in Listing 24-19.

import { NgModule, ErrorHandler } from "@angular/core";

import { BrowserModule } from "@angular/platform-browser";

import { MessageComponent } from "./message.component";

import { MessageService } from "./message.service";

import { MessageErrorHandler } from "./errorHandler";

@NgModule({

    imports: [BrowserModule],

    declarations: [MessageComponent],

    exports: [MessageComponent],

    providers: [MessageService,

        { provide: ErrorHandler, useClass: MessageErrorHandler }]

})

export class MessageModule { }

Listing 24-19.

Configuring an Error Handler in the message.module.ts File in the src/app/messages Folder

The error handling function uses the MessageService to report an error message to the user. Once these changes have been saved, clicking the Generate HTTP Error button produces an error that the user can see, as shown in Figure 24-4.

Summary

In this chapter, I explained how to make asynchronous HTTP requests in Angular applications. I introduced RESTful web services and the methods provided by the Angular HttpClient class that can be used to interact with them. I explained how the browser restricts requests to different origins and how Angular supports CORS and JSONP to make requests outside of the application’s origin. In the next chapter, I introduce the URL routing feature, which allows for navigating complex applications.