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.
Related
Is there advantages/disadvantages in these approaches?
I saw some programers using /api as reverse proxy to the API. Some are using api directly in clients.
I have an application with clients as React and mobiles. Not sure about best approach here.
As one disadvantage of /api - in case of Web application down our API will be unavailable for mobiles too.
I have SPA app with backend REST API (Symfony) with JWT authentication and necessary methods to communicate with my frontend app (Angular). And now i want to add another service ( Magento ) to comunicate with my backend.
Should Magento use same methods including authentication or its better to create separate module in my Symfony app with it's own methods?
You should reuse what is possible and makes sense, and only create separate API resources for new functionality. There is no point to create duplicate logic, unless there are differences between the use of the two consumers.
I have lot of webapis which are developed and deployed independently.
Each API would have routing for ex:
api/FirstApi
api/SecondApi
These will be deployed under www.myapis.com/.
If I create application for each of the api(s) in IIS, I would access the api as follows
www.myapis.com/FirstApiApp/api/FirstApi
but I want to access it as.
EX: www.myapis.com/api/FirstApi
Or: www.myapis.com/api/SecondApi
I want to remove the application FirstApiApp OR SecondApiApp from the url.
Is it possible to configure this pattern in IIS?
You could have the following structure:
c:\inetpub\wwwroot\api\FirstApi
c:\inetpub\wwwroot\api\SecondApi
And then have a website in IIS mapped to c:\inetpub\wwwroot and inside the api folder you have the 2 applications configured like this:
This assumes that you should drop the api/FirstApi routing from your Web APIs and map them to / directly because the first part will be provided by IIS. If you don't do this the request will become www.myapis.com/api/FirstApi/api/FirstApi which is not the goal here.
This being said, personally I would recommend you against doing this. A better approach would be to have a reverse proxy such as nginx or HAProxy in front which will route requests to /api/FirstApi to for example backend_node:8080 and requests to /api/SecondApi to backend_node:8181. This would allow you to deploy your Web APIs in two separate website in IIS listening on two different ports and keep the routing job to the application layer and not the infrastructure.
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 have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.