I am in the process of learning angular and I am a little confused as to what the difference is between cross domain and same domain requests. How do you know which type of request you are making?
Angularjs is a front end framework. You need a server component(rails, node.js etc) to handle requests from angularjs and handle the data(Users, post, comments etc).
If you are developing an Angularjs application that sends a request to a server that is NOT located with in the same domain/website, then it is a cross domain request. If you are developing an Angularjs application using a server that is contained with in the same domain/website, then it is a same domain request. If you want to develop an Angualrjs application using cross domain requests, you need to learn Cross-origin resource sharing(CORS) which defines how the server handles request from another domain/website.
Related
I'm having an issue with a project I'm working on. I have a Vue client which does API calls to my backend which is written in .NET Core 3.1. Both these applications are deployed on diffent servers.
Now the problem is that my backend server does not allow me to do API calls straight from the browser. So I have to do some kind of 'redirect' on the client server to reach my API.
So for example:
If I call backend_server/api/values I get an error (Firewall).
I think I should make like a second API or something, but I'm not sure how to handle this issue.
Does anybody have any experience on this? Any help is welcome!
Kind regards
You can have multiple options here
Remove the firewall rule -
This will allow your API to get hit from browser. If firewall is not managed by you you can't do this
Add IP or Port exception rule in firewall -
Instead of deactivating the entire inbound rule on server, you can allow specific ports or IP on firewall. Again if you have control on firewall
Create Proxy API -
Another way is you can create a middleware API that forwards your request and acts as a proxy. This will suffice performance, resource, time and compromise security. I recommend not to do this, But it's easily possible in .NET Core
Specify CORS policy -
If your Vue.js and API originates from same origin (IP), You can configure CORS in server which will restrict access to API only from same origin. That means only www.google.com can access GoogleAPI, Likewise. This will protect the API from other origins
Tunnel via VPN -
If security is a concern, Use a VPN service to tunnel your API requests. This can't be possible for every client using your web service.
The best way is to open a specific rule on server for your application if possible. Writing a proxy in between will have lot of disadvantages although can be accomplished.
i am taking a course in web data so i understand that when we want to retrive a webpage on a browser we do a request response cycle using a communication protocol like http or https and a web service is a piece of software which i dont know where it is stored or how it is accessed so we can make two applications from different architectures communicate using a serialization language like XML or JSON i dont know what is the difference between a web service and http they are both a way to connect 2 different computers together and what confused me the more is api which according to the research i did is something used to access web services.
Let's begin with defining all the terms in your question since it's a bit all over the place.
HTTP (Hypertext-Transport Protocol): Allows you to transfer data over the web. Your browser will perform a request using HTTP to your web service.
Service: Any software that performs a specific task. We are interested in a web service, which is typically invoked via HTTP, however this can be anything else such as a Linux signal.
For now, let's assume it listens on HTTP.
API (Application Programming Interface): An interface by which all clients of your software have to abide by to use it. For example, in our web service, we can dictate an API so requests follow some convention.
Let's put it all together now.
You're making a website that wants to calculate the sum of two numbers. First, users will go to http://yoursite.com, and then the browser will always do an HTTP request to the domain yoursite.com on port 80. This will hit either your hosting site or some backend server.
Here you have the option if you're using something like GitHub pages to serve static content or you have some server (i.e., serverd) that will load a file and serve it.
So now the web-browser did an HTTP request and your webpage should load with an index.html. The user can now click on buttons, and everything looks good until they press Calculate -- what happens now?
We want to offload the computation to our backend. We perform an HTTP request to our backend server. We can define an API, that is in our case an endpoint, so that the HTTP request can hit it and it'll return the sum of the two numbers.
How do we return the result? We need to represent the data somehow, and this can be done through a body payload that is encoded as either JSON or XML. Again, this is a serialization format and can encode it in various different ways. JSON is nice because you can parse it easily with JavaScript on the client side.
Great -- so now we got an entire site and it works! Now we can do an HTTP request from our browser straight to the backend according to our setup endpoint and it should fulfill our request. Notice how now we're using the API from the backend server from within our site.
Other keywords you can may run into: CORS, AJAX, Apache Server; good luck!
I have a front end written in react and a backend API which connects to a db for getting data. They have been written separately and are different services.
The front end server has a bunch of routes that connect to the backend API and I'm wondering what are the pros / cons of having these routes instead of directly accessing the backend API?
An example of the structure:
Front end server serves index.html and browser.js.
Browser.js makes GET, POST, PUT requests to front end server.
Front end server takes these requests and then makes a GET, POST, PUT request to the backend API.
Alternative:
Front end server serves index.html and browser.js.
Browser.js makes GET, POST, PUT requests to backend API.
So what are the pros / cons of doing it either way? The prior developer before me told me they did it the first way to bypass CORS and obscure the IP address of the backend API. However that doesn't seem to me like it is worth the trouble considering all the extra code, tests, etc the front end server has to write and maintain, in addition to extra network hops. I'm wondering if I'm missing some other more crucial reason that my inexperience cannot see? (My gut says do it the second way). Note that we are in a microservices architecture .
Front end server takes these requests and then makes a GET, POST, PUT request to the backend API.
The pattern that you describe is called API Gateway and it has the following characteristics:
Benefits:
Insulates the clients from how the application is partitioned into microservices
Insulates the clients from the problem of determining the locations of service instances
Provides the optimal API for each client
Reduces the number of requests/roundtrips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also means less overhead and improves the user experience. An API gateway is essential for mobile applications.
Simplifies the client by moving logic for calling multiple services from the client to API gateway
Translates from a “standard” public web-friendly API protocol to whatever protocols are used internally
Drawbacks:
Increased complexity - the API gateway is yet another moving part that must be developed, deployed and managed
Increased response time due to the additional network hop through the API gateway - however, for most applications the cost of an extra roundtrip is insignificant.
Conclusion: if you don't need the advantages that the API Gateway provides then you should not use it.
I'm currently developing an HTML5 mobile web app for Blackberry using WebWorks that interacts with a 3rd party API.
Unfortunately i can't use the API directly from the mobile app due to the cross domain requests constraints, so i'm considering the development of a Web Proxy that interacts with the API and serves the web app.
Since I've never done such thing i would like to get some recommendations, i'm going to use Microsoft technologies (.NET) to achieve my purpose.
I'm thinking about a WCF service that makes all requests to the API and the mobile client connects to the WCF service to get the data, but i think i'll have the same cross domain requests limitation anyway so it might not work.
First, check with your third-party API provider if they support CORS. If they do, you can get around the same origin policy restrictions. Assuming they don't, you can create a facade service using ASP.NET Web API instead of WCF. ASP.NET Web API is designed from the ground up for creating HTTP services for broader reach and there is no SOAP involved.
From your ASP.NET Web API, you can make a HTTP call using HttpClient and simply pass the request to the third party API and echo the response back to your app. As you rightly said, the same origin policy restrictions will apply to this case as well but you have more control over the server side. You can implement CORS in ASP.NET Web API and that way your BB WW app can still call your web API despite being in different origins.
I'm developing an Rest API in Node.js / express to expose resources (to Backend). And another web application that manages Sessions and interacts with the Rest API (to Frontend).
API and WEB_APP, is in same domain, with subdomain in both:
Backend: api.example.com
2 Frontend: www.example.com
The web application is accessed from client with angular.js.
The architecture would be for two situations:
Main_Rest_API <-> WEB_APP <-> Browser_User
Main_Rest_API <-> Rest_SDK <-> Client
My question is:
This architecture is consistent?
What would be the best way to implement this scheme?
Update:
I have to implement this architecture to provide Restfull via OAuth2 to third-party clients also
I don't really understand your question,
are you sure that you need separate servers for serving the web app and for the API? you'll need to handle cross domain requests this way.
if you don't actually need two servers, it'll be simpler to have one app, where /api/ routes (for example) are the REST API. then your AngularJS app can make AJAX requests to /api/
and / will serve the JavaScript web app.
again, I don't understand your question for the case you do need two separate servers.