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.
Related
I've seen that Azure App Service mobile apps can implement authentication for multiple identity providers via a single client SDK. If an app hosted on Azure App Service is using ASP.NET Core in the cloud, though, can its UWP or Windows Store client app also benefit from multiple identity providers via a single client SDK?
If yes, then how does that work? Does it use the same mobile client SDK?
If no, then how would I authenticate such a mobile client? Will I have to use individual provider SDKs?
I know ASP.NET Core is still prerelease, but I'm wondering:
What multi-provider authentication functionality is available from a mobile client now?
What such functionality is planned to be available when ASP.NET Core 1.0 is finally released?
What such functionality will likely be on the roadmap for the future?
Azure App Service provides authentication as a service. In other words, the client authenticates to the service, and the service passes on the authentication to you.
Underneath, the app service passes a number of authentication related app settings within environment variables that you can read via the normal method. The original JWT is also passed in via the X-ZUMO-AUTH header.
For your clients, probably the best way is to use the Azure Mobile Apps client SDKs - there are clients for .NET (Xamarin, UWP), JavaScript, iOS and Android. You don't need the data access functionality - just the client creation and login / loginAsync method calls.
For your server, take a look at the Authentication Overview for more information. You may also want to read some of the info in Chris Gillums blog for more technically details.
I want to build a new mobile app backend. This backend might eventually support other types of clients such as desktop or traditional web application.
In the past for multi client applications I would use this stack of technologies. SQL Server -> Entity Framework -> TCP WCF Service Endpoint -> MVC Web Application or WPF Windows Application
I know I want my mobile client to be consuming a Restful Http Web API like the types you would host in the new Azure API product. But I'm not sure if I should still do the WCF layer or not.
Couldn't all my clients consume just the Web API now? Or would it still be wise to develop the WCF service and the layer Web API on top of that?
It just doesn't seem right to be using 2 different serialization technologies at the same time.
Yes, you could replace that with Web API and create a REST API but as Tim already mentioned on his comment, that is obviously just HTTP and not all the protocols WCF supports.
Having said that, API Apps have Swagger metadata to describe what the REST URIs (endpoints) can do (e.g. methods, content types, descriptions etc.). There are a lot of Swagger SDK generators which can read the Swagger metadata and generate the code you need to consume the REST API in your application for pretty much any language out there. For Visual Studio 2013 with the latest Azure SDK, you have this capability built in as well. This is pure code generation, no tight coupling or anything, we just generate the code you were supposed to write to consume the API.
I'm planning to develop a pos application for restaurant. Client will be using pc and mobile. Application will be used in local area connection. I'm still considering whether to go with wcf or web api. What are the advantages of using wcf/web api for the type of application i'm building?
Use WCF to create reliable, secure web services that accessible over a variety of transports.
Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients.
Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API.
If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.
from the official Microsoft Documentation.
Essentially, my take on this is that WCF is much more difficult to work with, and not completely compatible out of the box with many mobile clients, so only use it if you know that it's something you need.
I have an issue that I am seriously struggling with.
I have a website, and a separate WebAPI which I want to be able to authenticate against each other. I was thinking that forms authentication would be best here. However, on my website, how do I go about calling the forms authenticated webAPI via a jQuery AJAX call?
Does anyone have any links or suggestions?
There is a discussion in this blog post on mixing forms authentication and basic authentication in Web API. You may be able to leverage some the principles in this article although it was tested with the Web API's residing on the same server as the web application.
If you keep the Web API and web application on separate servers your web application will run into cross domain issues and will have to support JSONP in your Web API. A possible work around for your website is to create a Web API locally on your web server which is just a facade to the Web API on the remote server. You incorporate the standard security methods on the local Web API, using AuthorizeAttribute, which in turn just calls your the Web API on the remote server. You can incorporate whatever security method you want to have for external users on the remote Web API.
I've been reading up about MVC 4 and was interested in the web API feature.
In what scenarios would it be advantageous to use web api over a WCF Http service?
Web API provides far more access to all aspects of the HTTP interaction. It was designed from the ground up around the HTTP spec. WCF is fine if you are just using HTTP to get through the firewall. If you really want to use HTTP as an application protocol, you will find Web API much easier.