I've never heard this question answered clearly- "Is angularJS's $http a push or pull mechanism?"
Update: Due to the comment I've received, I've modified the question to make it clear that my question is not about what $http actually does via TCP. I'm concerned with the way in which $http relates to the digest cycle.
Further clarification:
option #1: $http is used pull mechanism manner (like a suspect it is) and it calls the assigned REST API when it is provoked (perhaps on every digest cycle?).
option #2: $http uses a push mechanism, which means that $http has to rely on server APIs that are smart enough to push updates to each and every subscriber. I doubt that this is the case, but I wanted to ask.
P.S. I plan on running some tests to discover this answer myself, but I wanted to get some scholarly thoughts from all you fine people.
$http is a service that allows sending AJAX requests when you call it. It does not call a REST API at each digest cycle as you claim it does. And it doesn't receive any notification from the server.
You don't need to write any test to discover this. Just read the documentation.
I suspect it's never been "answered clearly" because it isn't really ambiguous.
It makes HTTP calls, period. You don't push from the server using a client call.
Related
Scenario:
I have a Node and Angular web app.
It needs to call an external api (a third party service) for data (more specifically this: https://api.represent.me/api/questions/).
Question:
Is it better to make this external call from the Angular frontend: GET http://thirdpartyservice.com/api/data or have the frontend calling a same domain Node endpoint: GET http://example.com/node-backend-api which then calls GET http://thirdpartyservice.com/api/data which then fetches and processes the data from the third party api before passing it back to angular?
Thoughts:
I guess two api calls is less desirable, but it is on the same domain
so would this not really be an issue?
GETing from the Node side would be more secure (especially if secret
keys were used), and also mask the fact that a third party service is
used.
CORS stuff might get in the way if calling from the frontend.
Is context key here, e.g. calling font apis from the
frontend is probably best, but fetching and needing to process data
is probably better from the backend.
What do others recommend (and do) and are there any other for or against points to add to the 'thoughts' too?
It depends on what your 3rd party API requires.
If you need some credentials to call the API it's probably better to handle the call in backend because of security concerns.
If the API delivers time sensitive data, like some auto-complete information as you type, it might be good to not do the extra roundtrip to the backend and call it from the frontend.
You might create a subdomain which points to the 3rd party server,
like 3rdparty-api.yourdomain.com, this removes a lot of cross-domain issues. But this needs cooperation of your 3rd party provider.
So, there is no clear yes or no answer but it depends on the situation and focus of your API.
Your solution looks fine, the only thing that may get in your way is if the 3rd party API you are using provides any sort of analytics. If you call it from Node you will overwrite the Agent and IP information that would be gathered if you called from UI. Other than that, I believe making the request directly from UI could reduce a little bit the load on the server, but I don't know if that matters to you.
I would say we should also take care about code duplication. In your case you are all JavaScript, but that is not true for many others. So let's say I consume api.github.com so I will not want to make some calls from frontend and some from the backend, then I think creating a controller which will handle all of this is a good choice.
Except for the cases like any analytics or tracking software, an extra round trip is ok.
As #Wolffc said, this can also prevent sending access_token to the browser which may be misused.
In an Angular service (provider.service) that uses $http, is there a way to periodically turn on and off what certain calls using $http will return?
Here's my scenario: we are using $http to consume web services built by another development team. When those services are not yet ready (or break) we don't want development efforts to halt on our end. We simply need to temporarily turn off that specific call and have it return mocked data.
I've seen $httpBackend being used to mock out HTTP calls, but I'm not sure that will work for me, and if it would, I'm not sure how this would look or be configured.
If you are making your $http calls from a data service, you can set toggles in your service. Don't even make the http call if you know it will fail. Alternatively you could probably even make a whole mock data service to use at dev time, and replace it with the actual service when your backend is ready, avoiding issues of dev code being there in production. This is one of the reasons people say you should never reference $http in controllers.
See the AngularJS Style Guide - Data Services for a better explanation than I could ever write.
Is there any point in using RestAngular if most of my calls don't end up being the usual RESTful GET all, GET by id, PUT, POST, DELETE, etc?
I understand the beauty of it for RESTful, but am I wrong in not seeing the advantage when I end up having other methods in my controllers? (E.g. returning a Dto of multiple joined tables).
Obviously the fact that you don't have to type out the full url is still there, but that's addressed by a "baseUrl" constant when using $http.
There is some benefit in that you can inject pre and post processors for requests, but for the most part, I find your assumption correct that there is little benefit when dealing with not strictly restful endpoints.
I would also recommend that $http requests reside in services and not in your controllers.
I am new in Angular.js, and just learning it.
I am looking on $http service to send AJAX request.
I got three ways to send AJAX request form Angular.js.
These are here
AJAX calls via the $http service.
JSONP calls via the $http service.
REST type calls.
Actually I am getting confuse to these three process, that which is better for me to use.
Which will be more efficient and reliable for me to implement it in my project?
My main aim to make it high throughput.
Any suggestion will be helpful for me.
If you are a beginner I would recommend you to go with the $http. Which is pretty straight forward and simple to use and serves most of the regular development tasks. The other two requires fair amount of understanding though they do the same job making ajax calls.
I've been working on a REST implementation with my existing Cake install, and it's looking great except that I want to use HTTP Digest Authentication for all requests (Basic Auth won't cut it). So great, I'll generate a header in the client app (which is not cake) and send it to my cake install. Only problem is, I can't find a method for extracting that Digest from the request...
I've looked through the Cake API for something that I can use to get the Digest Header. You'd think that Request Handler would be able to grab it, but I can't find anything resembling that.
There must be another method of getting the digest that I am overlooking?
In the meantime I'm writing my own regex to parse it out of the Request... once I'm done I'll post it here so no one has to waste as much time as I did hunting for it.
Figured it out. It's already accessible via PHP as $_SERVER['PHP_AUTH_DIGEST']
So then you pass to parseDigestAuthData($_SERVER['PHP_AUTH_DIGEST']);
<bangs head against wall>