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.
Related
I am little confused about these two technologies ie WCF REST and asp.net WEB API. Is there any difference between these two? When should use one over the other?
I am little confused about these two technologies ie WCF REST and asp.net WEB API. Is there any difference between these two?
Yes. Both are a means to providing REST-style services however the competing technologies are not created equal.
WCF REST naturally comes from the WCF world which is originally SOAP. WCF REST changes that by providing a rudimentary JSON payload instead of SOAP. However WCF REST is missing certain features and Microsoft has said that newer REST features will only make its way into ASP.NET Web API.
Unlike WCF REST, ASP.NET Web API has been designed from the ground up for REST-style JSON services.
MSDN:
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. - Tell me more
OP:
When should use one over the other?
If your intent is to create SOAP services, or you have an existing WCF service, use WCF with a JSON encoding endpoint.
If your intent is to create REST services, particularly in a new application, then use ASP.NET Web API.
It depends what you want to do for choose one of them
Basically with the WCF you can create service based applications
but with ASP.NET Web Api you can create Restful services based on Http or Https.
REST and WCF are the meanings from different worlds :) REST is a specification (in other words the set of conventions) for developing the web-services. REST doesn't depends on some special technology / platform / framework or language. WCF is Microsoft approach for web-services, natively predifined to develope SOAP-services, which are based on RPC-architecture. RPC (remote procedure call) is an approach to develope web-services as a set of methods with parameters, which are doing some work. REST is more HTTP-oriented and the main concept is to operate with some entities (Representational State Transfer) and perform actions to this entities, but not just call some methods. It is possible to build some REST-service using WCF technology, but in my opinion, WCF isn't a good way for this goal.
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'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 built a web service (WCF) as part of our company product, to support mobile devicies. The service is exposed via SOAP and is consumed by Android and Windows Phone 7 clients. Now we are spreading and need to add support for iPhone clients and those lazy iPhone developers are complaing, that they won't use SOAP, because its terrible, microsoftish, bloatware and there is no sufficient framework for that, etc etc and JSON ftw!
As it is WCF it was easy to create json api for this web service (new interface and little changes in web.config, love WCF!), the only problem is that I am using the built-in WCF Authentication service for authorization and this service is of course exposed via SOAP and I didn´t find a way to make it REST with json. So is there a way to somehow make it RESTful and consume/respond json?
My actual plan is to make another auth service, that will internally just call the existing WCF one via SOAP, but I don't like this workaround. I assume that, if there is not a way to make the WCF one RESTfull, later or sooner, I end up writing the auth service, which in my opinon will not be that hard.
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered #serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.