Month: July 2015

It uses promises. Instead of doing the “magic” filling of objects like $resource, it uses promises.

You can use this in $routeProvider.resolve. As Restangular returns promises, you can return any of the methods in the $routeProvider.resolve and you’ll get the real object injected into your controller if you want.

It doesn’t have all those $resource bugs. Restangular doesn’t have problem with trailing slashes, additional : in the URL, escaping information, expecting only arrays for getting lists, etc.

It supports all HTTP methods.

It supports ETag out of the box. You don’t have to do anything. ETags and If-None-Match will be used in all of your requests

It supports self linking elements If you receive from the server some item that has a link to itself, you can use that to query the server instead of writing the URL manually.

You don’t have to create one $resource object per request. Each time you want to do a request, you can just do it using the object that was returned by Restangular. You don’t need to create a new object for this.

You don’t have to write or remember ANY URL. With $resource, you need to write the URL Template. In here, you don’t write any urls. You just write the name of the resource you want to fetch and that’s it.

It supports nested RESTful resources. If you have Nested RESTful resources, Restangular can handle them for you. You don’t have to know the URL, the path, or anything to do all of the HTTP operations you want.

Restangular lets you create your own methods. You can create your own methods to run the operation that you want. The sky is the limit.

You can build your own URLs with Restangular objects easily. Restangular lets you create a Restangular object for any url you want with a really nice builder.

$http – $http is built into Angular, so there’s no need for the extra overhead of loading in an external dependency. $http is good for quick retrieval of server-side data that doesn’t really need any specific structure or complex behaviors. It’s probably best injected directly into your controllers for simplicity’s sake.

$resource – $resouce is good for situations that are slightly more complex than $http. It’s good when you have pretty structured data, but you plan to do most of your crunching, relationships, and other operations on the server side before delivering the API response. $resource doesn’t let you do much once you get the data into your JavaScript app, so you should deliver it to the app in its final state and make more REST calls when you need to manipulate or look at it from a different angle. Any custom behavior on the client side will need a lot of boilerplate.

Restangular – Restangular is a perfect option for complex operations on the client side. It lets you easily attach custom behaviors and interact with your data in much the same way as other model paradigms you’ve used in the past. It’s promise-based, clean, and feature-rich. However, it might be overkill if your needs are basic, and it carries along with it any extra implications that come with bringing in additional third-party dependencies.