Implementing REST services in AngularJS using Restangular

Current web development trends are in favour of AngularJS. The framework is having its momentum and is one of the most popular choices for client side development frameworks. Personally, I like it a lot, it makes my job easier to jump start the web development projects quickly. It is also useful for hybrid mobile applications.

Another thing that has quite a momentum for some time now is implementation and consumption of REST services. REST as an architecture, although it makes things easier after implementation, is an architectural style which is very easy to get it wrong, despite most of the time what we need is simple GET/POST/PUT/DELETE requests.

Restangular is an AngularJS service which makes GET/POST/PUT/DELETE requests simpler and easier. The configuration is easier and can be done in several ways with different initiation settings. Let me try to put an easier demonstration on how to use Restangular on your site and how easy it is to make your AngularJS app consume RESTful service.


The first thing to do is to reference restangular in your index.html (refer to official page for installation).

To configure restangular with your AngularJS app, in your app module definition file you configure restangular settings.

Now that we have restangular configured, we can make requests for resource like this:

Alternatively, we can also create services for our resources. For e.g. if I have a resource named students, I would create the service through these lines of code:

then I would add this service as a dependency to the controller that I want to use it in. With this simple service definition, I can now easily initiate GET/POST/PUT/DELETE requests through restangular.

Let us take some examples. We can read all students by requesting

or if I want to read the student with id 1234 I would request

Saving a student is also as easy as getting it

Restangular has the main request types GET/POST/PUT/DELETE almost ready made for us, but also it allows many things to be configured per our needs. We can make custom requests to custom methods, specify parameter names, and many other not so standard things. Please refer to restangular’s github page for detailed specifications.

As it makes RESTful api consumption so simple, currently it is one of my favorite parts of my AngularJS apps.

Web services vs. SOA and pretty URL vs. REST

It has been quite a time since Service Oriented Architecture (SOA) and Representational State Transfer (REST) architectures are around, yet there are some misconceptions about them I hear very often, which I would like to discuss here.

1. Having web services does not mean you have an SOA architecture

This is perhaps one of the biggest misconceptions about SOA architecture I hear very very often. I see many developers thinking that if they have a web service or two in their architecture, they say their architecture is an SOA architecture. I think this comes because of two reasons: 1) “Web service” and “service oriented” resemblance in naming makes people think they are the same thing; 2) As web services are the most common way of implementing an SOA architecture, this pushes people think that when they have created one web service, their architecture is an SOA architecture.

An SOA architecture is characterized of composition of independent services which encapsulate business functionality and expose it as a service, which can be  a web service, a windows service,  or any other form of exposure. Ubiquity of web and advancement of web development technologies which made the creation of web services easier have put web services as a mean of choice for implementation of an SOA architecture, however, the definition of a service within an SOA architecture does not put web services in any special position regarding implementation of SOA architectures. Here is the definition of a service from Open Group:

A service:

Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
Is self-contained
May be composed of other services
Is a “black box” to consumers of the service

 Web services and SOA make a great pair which power a lot of important and popular service out there, but it should be crystal clear to Software Architects, Developers, and anyone contributing to software developments that having web services does not mean you have an SOA architecture.

2. Having pretty URLs does not mean you have a REST architectural style

REST architectural style is another popular topic lately, and as such, is subject to a lot of misconceptions as well. REST has brought simplicity to implementation of web services and is embraced very popularly from the web development community. It plays well with the HTTP protocol, which we are familiar with ever since the beginning of www era.

One characteristic of REST architectural style is that resources are at the center of the architecture, and they are beautifully represented in URLs. REST has brought us pretty URLs, and therefore people have created a connection between the URLs and REST architecture. Leonard Richardson has developed a maturity model which tells the level of your API or RESTful services to what degree are RESTful. Martin Fowler has a great post about richardson maturity model. The levels are described as in this picture:

richardson's rest levels of maturity for REST

The very first level of the pyramid, level 1 is the implementation of URI or introduction of resources and at this level of implementation resides using the “pretty” URLs to connect URIs to resources. The level 2 refers to using HTTP verbs and the most advanced level, level 3 refers to using hypermedia or following HATEOAS.

In Richardson’s model is clearly seen that pretty URLs are the very basic level of implementing RESTful web services towards a REST architecture and clearly explain that having pretty URLs to access your services does not mean you have a REST architectural style in place.

In my opinion, implementing an SOA architecture and RESTful web services requires to have a clear understanding of these concepts, the constraints which come with them, and what is required to have such an architecture in place. Clear understanding will lead to effective architectures which allow us to reach the promises and benefits of these architectural styles.

Architecture of web applications

I consider software development more art than exact science, and as such, in software development almost always there is not a single way of solving a problem. Although there are defined best practices, it is a matter of problem being solved and the knowledge of the team that influences most the definition of the architecture of web applications and software applications in general.

Recent years has brought to popularity using REST in the architecture of web application solutions. I am a huge fan of REST, I like it a lot mostly because of its consistent way of expressing CRUD operations and brings simplicity to the API implementation. The use of REST has been pushed further with advancement of MV* JavaScript frameworks as they tend to have a natural way of consuming resources from REST APIs.

Lately, I am seeing that most newly built web applications tend to use REST in some way, if not exposing APIs, they do consume one or more of them. In my opinion, REST tends to create a viral effect on developers, as much as you use it, you want more of it. Now after we experience REST, I think there is a question which pops up:

Do we have to expose everything as REST API?

The universal answer “it depends” applies here very well! If you want to use a client side framework such as AngularJS that does not need server-side code and is well suitable to consume REST services, it might be a very good idea to expose the whole business logic as REST API and consume it through AngularJS services. This comes with additional benefit that if you want to have a mobile app of your web application, you do not have to write any additional code on server-side to support your mobile app, just consume the very same REST services and you are good to go. A diagram representation of such layered architecture of web applications could look like this:

Web application architecture with REST API and client side MV*

This is one of the most often used architecture styles I am seeing these days in web applications. However, what if you are not keen to using MV* JavaScript frameworks and want to use a server-side backend and generate your HTML representation using let’s say ASP.NET MVC. Do you still need to expose business logic as REST API?

Exposing business logic as REST API or any other form of service layer, if you do not have multiple types of consumers (web, devices, etc.), in my opinion is waste of resources (time and effort). Exposing and consuming services do introduce a level of complexity (you need to put extra effort on error handling, security, versioning, asynchronous access, etc.)  to the architecture and application code. This complexity is non considerable if you have multiple consumers of your application as it avoids writing multiple times the same functionality, however, if there is only one consumer and it is the web GUI, then in my experience I have seen that it only makes things worse. In such a situation, going with an old style server-side backend is a lot more easier. If you say I have a mobile client as well which consumes part of the functionality, in that case I think it is better to create a small REST API service group exposing only that part of the functionality, is a better choice. This will also allow you to develop your web app and mobile app in different paces (if you have lack of developer resources, you shall come to this requirement). The modified version of our new architecture will look like this:

Web application architecture with server-side backend and rest api

Sometimes we are keen to jump to new technologies and architecture styles just because its presentation looks attractive and we like to get our hands in it and give it a try. Often this pushes us to situations which makes maintenance of our code base difficult in later stages of our application lifespan. It is very important that evaluation of the application architecture to be done as early as possible and be judged from the simplicity and maintainability perspective.