• No results found

Project details

In document Understanding API Security (Page 73-76)

This chapter covers

7.5 Project details

You’ll continue building on the preceding chapter’s used video game project by add- ing a shopping cart. As usual, you’ll use AngularJS for your MV* framework. It has built-in support for both promises and the consumption of RESTful services. As indi- cated at the beginning of this chapter, we discuss the server side of the application only conceptually here.

Because many server-side languages and frameworks might be used instead of what you’re using, I include a small summary of the tasks the server will need to perform for each call in appendix C. This way, you can create the server-side code by using a different tech stack if you wish. As always, the complete code is available for download. Let’s begin by walking through the setup of your data source.

7.5.1 Configuring REST calls

Earlier in this chapter, you learned about the $resource object from AngularJS. It makes consuming RESTful services easier, and its methods all return promises. You’ll use it for every server call in your project. Although I try to keep our discussions framework neutral, you’ll have to take a moment to further review how $resource works. It can be a little intimidating at first. After you walk through how it works, though, you’ll see how easy it is to use. After a gentle introduction to $resource, you’ll proceed with how it’ll be configured in your example SPA’s shopping cart service.

67

Project details

Creating URLs with AngularJS’s $resource

Like some of the other MV* frameworks, AngularJS offers support for RESTful service web service consumption out of the box by using its $resource object. This object adds a lot of sugar coating for the underlying XMLHttpRequest object to hide much of the boilerplate code you’d have to otherwise write yourself.

The main goal of $resource is to make it easy to work with RESTful services. Having a consistent and uniform way to represent resources is one of the principles of REST. After a URL style has been established, the $resource factory will help you create URLs that conform to this style easily.

The $resource factory enables you to define a template that will create resource URLs for each type of REST call you need to make. To use $resource, you can pass a URL, optional default parameters, and an optional set of actions to its constructor:

$resource(DEFAULT URL, DEFAULT URL PARAMS, OPTIONAL ACTIONS)

The following will serve as your default URL:

"controllers/shopping/carts"

The default will be used if you don’t override it. But in this project, you’re defining custom functions that will override it with their own URLs. Each custom action can have its own. To construct the URLs in the structure needed by your RESTful web ser- vices, you can use URL path parameters. As with routes, using a colon in front of a string in the URL indicates a parameter. Here’s an example URL from your configura- tion that includes URL path parameters:

"controllers/shopping/carts/:cartId/products/:productId"

The next argument, the optional parameter list, acts like a data map. It tells the $resource object that in one or more of these calls, this optional parameter list may

be used. This list is in the form of key-value pairs. The left side is the name of a parameter in the URL. The right side is the value for the parameter. The @ symbol tells $resource that the value is a data property name, not just a string. With it present, the data object passed in will be scanned for a property with that name, and its value will be used in the URL’s path.

{

cartId : "@cartId", productId : "@productId " }

For example, if you passed in an object called myCart for the call, then the value for the URL parameter cartId would come from myCart.cartId. The value for the URL parameter productId would come from myCart.productId.

The nice thing about using $resource as a REST URL template is that you get a set of REST calls out of the box that are preconfigured with the following HTTP methods: get()—GET

query()—GET (intended for a list; by default it expects an array) save()—POST

68 CHAPTER 7 Communicating with the server

Now that you’ve looked at $resource basics, let’s look at the entire code for the $resource instance used for your shopping cart (see the following listing). This will give you a picture of the type of calls that will be made inside the shopping cart service.

var Cart = $resource("controllers/shopping/carts", { cartId : "@cartId", productId : "@productId" }, { // cart methods getCart : { method : "GET", url : "controllers/shopping/carts/:cartId" }, updateCart : { method : "PUT", url : "controllers/shopping/carts/:cartId" }, // item-level methods addProductItem : { method : "POST", url : "controllers/shopping/carts/:cartId/products/:productId" (continued) delete()—DELETE

remove()—DELETE (identical to delete(), in case the browser has a problem with the delete() action)

If you want to customize your calls as we’re doing, you can pass in the optional set of named functions (or actions in Angular-speak). You can use the action to create a completely customized call or override one of the out-of-the-box functions. For exam- ple, to create a custom action called updateCart(), you can include the following in your set of actions:

updateCart : { method : "PUT",

url : "controllers/shopping/carts/:cartId" }

After you have the $resource object configured, any calls you make with it automat- ically return a promise. You’ve already seen how to use them to work with the results of your calls.

In this chapter’s examples, you’re using $resource inside your shopping cart service because you have additional processes taking place before the data is returned to the controller. For simple data returns, you might want to wrap the $resource in another AngularJS object (such as a factory) and include it directly in your controller. To see the complete documentation for $resource, visit the AngularJS site at https://docs.angularjs.org/api/ngResource/service/$resource.

Listing 7.8 Configuration for your REST calls

Assign the $resource created to a variable Define default

parameters

Define actions for the rest of your calls

69

In document Understanding API Security (Page 73-76)