What's the difference between using $resource to make a put request and using $http.put to make a put request? Does it make any difference in the speed or performance?
Check Answers in this stackoverflow thread
$resource is further high-level abstraction of $http. I don't think $resource added significant performance burden on top of $http to get the high-level API .
Related
Basically, I am building a massive app, using SailsJS and AngularJS.
I'm ratter new to both of them.
I've started this app with few Controllers, but seeing how it's getting messy, I started to move the interaction with my Backend API into Services (mostly the $http functions). I quickly noticed that the "asynchonousity" of it messed most of my logic.
I never used the $q of Angular, and $http kind of do it by itself so I looked online to see the best practice and found this post : AngularJS services and promises best practice
As it's from 2016, I was wondering if it is still considered the best practice, and if it is exactly like that that I should build my Services.
It still is considered the best practice. You can use Promise Chaining in order to structure your code timewise.
You may want to see this article for further details.
Who can tell me at least 5 differences AngularJS standard $http and NgResource?
Expect that NgResourse is better for RESTfull Api.I searched for this but didn't find a good answer:(
Can I use either for a REST call ? Or is there some minor difference ? I have used both of them in my projects with no side effects,
These are the main differences between $http and $resource:
$http:
$http is for universal purpose. It is an Ajax call.
$http is built into the AngularJS framework.
$http is good for quick retrieval.
$http is injected directly into an AngularJS controller by the developer.
For more details about $http refer: https://docs.angularjs.org/api/ng/service/$http
$resource:
$resource wraps $http to use in RESTful web APIs.
$resource needs to add the module separately.
$resource is good for conditions slightly more complex than $http.
$resource does not allow us to do much with data once it is consumed in the application. It is in the final state when it is delivered to the HTML DOM. The data are the same that the $http method will receive.
For more details about $resource refer: https://docs.angularjs.org/api/ngResource/service/$resource
You can find more answer here and here.
When expecting a call to the API should I include the entire URL including all the parameters, or do I just need a partial match?
Should I be listening for a call to the exact URL :
http://address.of.api/stuff/123?include=thing,anotherthing.name;
Or do I just need this :
/stuff/123
$httpBackend is part of Angular's Mock environment designed to replace real backend by fake one, or rather by imitating how Angular's $http works without real backend.
As much as I love Angular, I find $httpBackend over-engineered and unnecessarily complicated for what it does:
It is not recommended way to throw complicated code inside your tests. The more you do it, the more chance is that you create errors in that testing code instead of what you are actually supposed to test.
It promotes the bad practice of placing $http (or other low-level services in your abstraction hierarchy) freely around your code, as you can later use that $httpBackend to mock it away.
Instead it works cleaner to isolate any reference to low level methods into dedicated methods of your own, whose single responsibility is to make http requests. These dedicated methods should be able to work with real backend, not a fake one!
More details here on Angular testing
tl;dr
I'm really struggling to find the appropriate pattern here. How should I best configure a generalized provider to a specific use-case? I can't use $http as a dependency in .configure(); can I?
longer, boring explanation:
I am trying to create a generalized provider which I may reuse in Angular. I have it working, however it requires configuration.
The intention is to provide a fallback REST service to use in saving data to the server, but with provision to save offline in local-storage. Therefore, I need to provide appropriate $http calls for each instance of this provider.
Is it possible to provide appropriate $http calls with .configure() or else should I try and figure out how to inject $http into the provider from the start and then configure it afterward??
It's frustrating... and may change in AngularJS 2.0... But for now, yes, it is not possible to do this. There is a very high wall between the .configure() and .run() states, so you can't access $http from a .configure() function. The reason is that it hasn't actually been created. At this stage, all that exists is the provider. Once all of the dependencies are configured, then the http provider will be used to make the real $http service.
I'm not sure exactly what you're trying to do, but there are two excellent AngularJS developers that are good to follow who have some advanced patterns in projects they've shared: Pascal Precht and Brian Ford. Here are two projects that make heavy use of provider/service concepts as well as $http-driven services:
https://github.com/angular-translate/angular-translate
https://github.com/btford/angular-modal
Angular Modal, especially, does $http work to load its templates. There might be use cases in there that are similar to what you're trying to do.