7

I've been working on a single-page web app that is entirely ajax-based (no POSTs) and for now I'm using ASMX for the web services while it's in development. The web services work with JSON data. For the release, I know I'll need to upgrade to either WCF or WebAPI.

Eventually, I plan to build native mobile applications that will work with the same web services as the web app. All things being equal, if I have to choose between the two, which option should I go with so that the web services can work with different client apps?

Thanks.

j0k
  • 22,600
  • 28
  • 79
  • 90
frenchie
  • 51,731
  • 109
  • 304
  • 510

2 Answers2

8

If your application is designed to be only accessible by mobile devices from various platform, it means you will have to find the common easiest denominator for all these platforms. So, in other terms, if interoperability is your concern, you will focus on one unique communication technology that all platform can use.

JSON + REST seems to be the common easiest denominator for many platforms today (of course including mobile ones). And if that's the only communication technology you will implement, WebAPI seems the obvious choice.

WCF is more extensible, more configurable, you can plug different bindings, different encodings, on different protocols, it implements SOAP, WS-*, it can be very fast (with carefully chosen bindings), you can also do JSON+REST with it, but you don't need all that power (and WCF can be also quite complex because of all these features), what you need seems to be ubiquity and simplicity. Given your requirements, I would choose WebAPI.

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298
6

I developed a set of RESTful web services using WCF, and recently started a project to replace WCF with ASP.NET Web API. My experience is that ASP.NET Web API is easier to learn than WCF and easier to work with. I can also give you a couple of reasons why you would want to choose ASP.NET Web API:

  • WCF urls include the '.svc' extension. For example: http://localhost/MyRestService.svc/. This shouldn't cause a problem with clients, but it's ugly. You can get rid of the .svc extension by using the IIS URL Rewrite module (see this blog post), but with ASP.NET Web API, you don't have the problem in the first place.

  • WCF uses the DataContractJsonSerializer, which generates JSON that can be problematic for clients. Specific examples include dates and dictionaries. You can change the serializer used by WCF (see this SO question), but ASP.NET Web API uses JSON.NET by default, which is highly configurable.

If I was starting out today and creating a new RESTful web service, choosing ASP.NET Web API over WCF would be an easy choice as this is what it was designed for.

Community
  • 1
  • 1
Jeff Ogata
  • 56,645
  • 19
  • 114
  • 127
  • First reason: It's just your point of view, I personally don't think it is ugly nor pretty :). Second reason: Good one! I had almost forgotten that the DataContractJsonSerializer has some surprises of its own that we only find out after playing with it for some time, like this one: [How do you handle Infinity in JSON generated in .NET](http://stackoverflow.com/questions/7997657/how-do-you-handle-infinity-in-json-generated-in-net) – Thomas C. G. de Vilhena Dec 13 '13 at 19:24