I had been using Angular-HTTP-Auth with the basic http requests, but have since moved to Restangular and are now finding that 401's are no longer caught by HTTP-Auth. I'm assuming this is because the Angular http methods aren't used or are intercepted somehow. Is there a method for making these work together again? I know that Restangular has interceptor's exposed, but I'm not certain how the 2 need to operate.
Related
I want to test my code with real API calls (so I can test the API as well, and when I change the API I don't have to change the JS test as well, and a lot more benefits.) instead of the regular $httpBackend.expectPOST('http://api.com/login').response(200).
Essentially, I want to test a ProductsController that expects to be logged in through an AuthService.login() method and receive a list of products through ui-router's resolve feature.
In this case, the login method receives data that needs to be used to gather products.
From the $httpBackend documentation found here: https://docs.angularjs.org/api/ngMockE2E/service/$httpBackend
As opposed to unit-testing, in an end-to-end testing scenario or in scenario when an application is being developed with the real backend api replaced with a mock, it is often desirable for certain category of requests to bypass the mock and issue a real http request (e.g. to fetch templates or static files from the webserver). To configure the backend with this behavior use the passThrough request handler of when instead of respond
So, something like: $httpBackend.whenGET(/.*/).passThrough(); should suffice.
a) What are the difference between $http and $q ?
b) When should $q be implement over $http and vice versa ?
c) When and best practice for implement $http and $q at the same time?
a) $http executes HTTP requests in an asynchronous manner, which means that you can not be sure about the time when you'll get an answer from the server. $q is a service that provides you the capability to execute multiple asynchronous tasks one after another. That being said they conceptionally do have nothing in common.
b) Consider a situation where you want to have multiple async HTTP calls to a server. You may have the possibility to nest each of those calls (for instance making the 2nd call in the success callback of the first call). However you find yourself in situations where you have various amounts of calls. You would then use $q to circumvent nesting code.
c) Whenever you have a single HTTP call you should use $http. Whenever you have numerous calls, you should use $q.
a)
$http = angular service for access a server via the http protocol.
$q = angular service implementing kris kowalkis q library https://github.com/kriskowal/q.
They are both angular service but have nothing else in common.
b)
$http uses $q to provide defered access (promises). But I know no situation where i would use $q over $http. As far as you want to make http requests.
c)
$http uses $q. So they are always used together. As long as you want to make http requests.
I am writing an AngularJs app to test an API we developed. The app uses the $http object to make requests to the API. One of the asks is that after the call it's possible to review the raw HTTP (headers and bodies) Request/Response, similarly to what's available in Fiddler via Raw tabs.
Is it something that $http provides out of the box?
If not, it appears that the only challenge is gaining access to the actual request http headers. It's easy to get the response headers and request/response bodies, but not sure how to get the actual request headers.
Thanks.
If you are using $http service to make your API calls, you can use Interceptors to achieve what you want.
Here is what docs tell us about them:
For purposes of global error handling, authentication, or any kind of synchronous or asynchronous pre-processing of request or postprocessing of responses, it is desirable to be able to intercept requests before they are handed to the server and responses before they are handed over to the application code that initiated these requests. The interceptors leverage the promise APIs to fulfill this need for both synchronous and asynchronous pre-processing.
You can find more in depth explanation in the official docs. For example, here.
Also, there are some questions about interceptors on this site. There are some examples of their usage for displaying loading screen in applications: here, here and, probably, somewhere else.
Hope, this helps.
Yes, AngularJs is wrapped around some JQuery or internally JQlite if JQuery is not present and written in Javascript and it provides some pre-defined services. A typical service looks like the following.
AngularJS docs: tutorial step 5
$ Prefix Naming Convention You can create your own services, and in
fact we will do exactly that in step 11. As a naming convention,
Angular's built-in services, Scope methods and a few other Angular
APIs have a $ prefix in front of the name.
The $ prefix is there to namespace Angular-provided services. To
prevent collisions it's best to avoid naming your services and models
anything that begins with a $.
If you inspect a Scope, you may also notice some properties that begin
with $$. These properties are considered private, and should not be
accessed or modified.
angular.module('myApp')
.factory('myService', function ($http, $injector) {
'use strict';
return $http.get('/endpoint')
.then(function () {
return $injector.get('endpoint');
}
.error(function () {
// handle error
}
};
})
Have a look a the image in AngularJS docs which shows a number of services with the $ prefix. Mostly, wrappers over service. It is reserved. More at FAQ.
I have an AngularJS application that talks to various java services. In the application I have a global http header setting in an http interceptor. That means all the service requests from my application will get the header values.
Now the trouble is that all the services CORS settings won't allow this header value. Couple of services does, while others does not. The service calls to the servers that do not support the header fails, since the http interceptor always puts the header values.
Is there a better way to design, in the above said case, so as to avoid the issue stated?
Appreciate any help...
How about adding a response interceptor, looking for a 401 status? If you get a 401, attempt to do the same request again without the headers this time. If this succeeds, 'whitelist' this domain to make all following requests without the headers that you don't want.
Otherwise, if you have a limited number of services that you are making calls to, maybe whitelist them inside of your request interceptor? This would probably be easier, but it's not very elegant.
I am currently building a dashboard page with multiple widgets. Those widgets retrieve their data with REST calls ($resource). A few widgets make similar calls and I don't want to DDOS our server so I am looking for a way to make a call only once and resolve all similar requests with the same response.
Since I am restricted to using POST requests only, I cannot use the cache option that $resource offers. This seems to be doing exactly what I want but only for GET requests.
I was thinking along the lines of using a http interceptor to queue similar POST requests, fire only one of them and resolving them all when the first one gets its response.
However, I cannot seem to put the pieces together so any help is appreciated. I am open to other options.
Kind regards,
Tim
Services in AngularJS are singletons, so a solution would be to store the response in the service, as a variable. Then next time you'll do the request, previously check if the variable is null, if it's not you wrap it in a promise and returned it. If it's null, then you do the request, and store the response for the next call.
You can also either use this in your request service or in your interceptor service.
I hope I helped !
Refactor your widgets to depend on a service (singleton).
This service should either poll the server via XHR, or get server push via websocket for updates.
If polling, look into server side caching and etags.