Chapter 8. Services and Business Logic

Not all AngularJS services connect to REST services. Services can also contain business logic that is used by multiple controllers. As I mentioned before, if the business logic can be moved to a REST service, that is where it should be defined. Defining business logic in REST services assures that the same logic will be readily available to all client-side applications.

Often, however, it is not possible to move all business logic to REST services. Often that same business logic is needed across multiple controllers. That is where AngularJS non-REST services come in handy once again. In this chapter we will look at several examples of where AngularJS non-REST services are useful.

Take, for example, a situation where a user needs to authenticate across multiple REST services. One way to do that is by using Basic Authentication, where the user’s username and password are passed to a service as a token in the HTTPS header during a service call. The token is in the form of “username:password” and encoded with base64.

As we know, a REST service shouldn’t hold state, and holding a user’s credentials in a session variable on the server is a serious security concern. Using a session variable to hold authentication state on the server side is usually not acceptable in most REST service designs. AngularJS services are great for handling such situations.

Handling User Authentication

First, we need a way to validate a user’s credentials ...

Get Learning AngularJS now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.