Services are always the last thing anyone mentions in conjunction with Angular, despite being the single most important part. It rather well kills the point of having a frontend framework if you can’t even get data properly from your respective backend. Great! Now that we have that out of the way, let’s dive right into how to implement a RESTful client in Angular to get you up on your data in high fashion!
The built in http methods, also known as rolling your own service.
This is the low level of making a request. As long as it fits in the scheme of HTTP you can define it here. This gives you a lot of power to take care of those fine little details.
The problem with having that type of power is that very very rarely can anything be described as special enough in a RESTful framework to necessitate fine grained control. If it does, you’re likely doing something very wrong and need to look at your implementation a bit more carefully.
When I say low level, I mean it. You have to handle setting up every method for every type of request. The only way to really overcome this is to set up a base service and define common methods, but by the time you do that, you’re already a great deal of the way to items further down the list.
If you see yourself there, it’s time to take a sober look in the mirror and ask yourself if you really want to invent the next RESTful service handler in Angular. Nothing against that if you have something clever, but chances are you just want to get work done, or at least you’re supposed to be getting it done.
An abstraction beyond $http allowing you to define a lot of the methods at once.
Unlike $http this allows you to define all of the resources in one swoop.
The Documentation is neigh unreadable and you’ll spend plenty of time fumbling through blog posts and whatever books you can find to get a solid implementation of them
It took a while for them to get to promises
Touted as solving a lot of the annoyances with $resource
You probably won’t need to bother with making Services, you can just drop in Restangular and use it in your controllers. Everything from that point on is a Restangular object you can call through on, and they all return promises. Very handy to get a lot of code out of repetitive services.
Want to do something out of the usual? Restangular can do it. You get custom methods for sending new types of requests, and you can even define your own methods on it.
Hopefully you like lodash (I do), because it’s a required dependency. This one is debatable, as I’m of the opinion that people should be using it more as is, but I digress.
What about relationships? You’re going to end up with a lot more code there, especially on trying to get many to many relationships to behave in anything that resembles coherence.
The custom methods are nice, but you’re going to very quickly see your controllers start looking like half-baked services. If you’re finding yourself defining a ton of custom methods for unique methods, you’ll find yourself going back towards services very quickly. Granted, that likely means you need to redesign systems on the backend, and of course there’s nothing against abstracting Restangular into base controllers either.
These objects can become heavyweight fast. All the Restangular methods are getting appended to the objects meaning you’re passing around a lot more data. If you send a
PUT request to create or update something, you had better hope you’re filtering paramaters.
You’ll end up getting a mouthful of Restangular chaff on every object you’re trying to send up, and the only way to get around this one is to run a cleaner on it. To me it seems like far too much work being done for far too little extra gain.
Eventually you get fed up with all of this and decide that there has to be a better way to manage all of this. If you’ve noticed a trend so far, it’s that each successive recommendation is an abstraction on the last. Angular Data is the culmination of getting far too pissed off at implementing base services and other nonsense trying to get Angular to behave coherently.
You can define relationships, have resources defined much in the same way as a Rails-like framework, and even bind data to the scope with very little extra code.
That means you get fun like
belongsTo. No more needing to create extra methods to get at nested data, and no need to repetitively define relationships.
The author is extremely responsive to issues and is known to have feedback within the day. Many of the frustrations above were things that he’d cited as reasons for creating this framework.
I’ve yet to have found anything compelling against it to this point, except that you need to be very specific in telling it how your server responds to queries.
So what wins?
Really it depends on how much horsepower you need to get tasks done, but as of now I would still put Restangular as the go-to for most occasions with angular-data being a very interesting up and coming framework.