Take the 2-minute tour ×

This question is in conjuction with How would you approach developing a Hotel Reservation System?

The solution to a system with different interfaces (or clients I should say) is to go with developing a Web service and have other systems interact with it.

I never had the requirement for developing a Web service so I am bit short on it. All I understand is that A web service is a system or application that performs some operations which may include modifying, sending or receiving data over a network using HTTP protocol. (Let me know if the understanding is wrong)

Now, from the other question it's clearly understood that I need to develop a web service but I have no idea as to how should I go about it. My language of choice is C# and .NET Framework.

Question: How do we develop a webservice and which tools, technology and framework should I use for the same using C# language?

Question: How can I interact with this from a desktop WPF application, website and mobile app.

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

"Web Services" are a fairly generic term to describe a data interchange mechanism that usually operates over HTTP (although not restricted to). There are many types of ways to implement web services and in particular, ways to exchange data.

SOAP Web Services

The type of "Web Service" most (.NET) developers are probably familiar with are SOAP web services. SOAP web services are pretty mature, well defined and have a whole bunch of w3.org standards and specifications. SOAP web service support is burned into most development frameworks, .NET has had SOAP web service support since its inception and the Visual Studio tooling makes it really easy to start building SOAP web services out of the box.

The problem with SOAP web services is that they aren't lightweight. You need to publish a WSDL document that describes the service and the XML interchanged between systems can be quite heavy due to the constructs used to assemble a SOAP message - Envelope, Header and Body.

The problem with SOAP messages is that they aren't easily or naturally consumed by web browsers (Javascript), you need to do a lot of work to make that happen or use something like Microsoft's AJAX client side script libraries that aren't exactly pretty or lightweight either.


Another, but older, type of "web service" protocol is XML-RPC. It's probably the daddy of HTTP web services and provided the groundwork for SOAP. XML-RPC is not well supported in .NET and as with SOAP has a fairly large metadata overhead in the XML payload just to send even small amounts of data. XML-RPC is also not easily or naturally consumed by web browsers.

Custom XML or other interchange formats

It's entirely possible to construct a web service that exchanges data using custom XML messages. In fact webservices don't even need to use XML (see below), you can even exchange data over HTTP using plain old CSV. However the disadvantage of using non-standard formats is that when you come to serialise or deserialise the interchange format then you're committing to writing your own custom code to do that. SOAP and JSON have built in support in many frameworks to serialise and deserialise your objects to and from these formats. Ideally you want to be using a format that your framework can understand and do the heavy lifting for you out of the box.


If you're going to be making calls to a "web service" endpoint and the consumers of these services are going to be varied (such as in your case), for example a .NET WPF application, AJAX calls from the browser or pulling data into a mobile application (iPhone, Android etc), then the one data interchange format to put at the top of your list is JSON.

JSON is a very lightweight data interchange format and has a multitude of libraries available for many different programming languages and platforms.

For .NET applications there is built-in support for serialising and deserialising JSON and there are also excellent third party libraries such as James Newton King's Json.NET library (which is my own preference).

For mobile applications, whilst there is fairly solid support for SOAP on most mobile platforms, JSON would be a better choice due to it being more compact, and compact has great advantages if your mobile application is pulling data over a low speed 2G or 3G connection.

JSON is also easily consumed by Javascript in the browser, Javascript will rehydrate JSON formatted data into objects you can use directly in your browser side script. jQuery makes transmitting and receiving JSON data between the browser and a web service a fairly pain free affair. In fact JSON is probably the de-facto way to consume web service data in the browser.

So, in conclusion and to answer your two questions -


To build the web service itself - web service endpoints built using ASP.NET MVC is probably the path of least resistance. You can use WCF but the learning curve can be fairly high and there's a fair bit of configuration and infrastructure code that comes along with the territory. However, there is a MS project on CodePlex called WCF Web API aimed at simplifying using WCF over HTTP, however it's still at the preview stage.

My advice would be to start by getting the hang of sending and receiving JSON over HTTP using ASP.MVC. Either use the built-in .NET JSON support or use something like Json.NET.

How can I interact with this from a desktop WPF application, website and mobile app?

  • To allow the WCF application to communicate with the web service above I'd certainly go with Json.NET to serialise and deserialise the JSON data and make your requests to the web service endpoint just using simple HttpWebRequest's

  • Browser based clients can make AJAX calls to push and pull JSON data between the web service and the browser. The path of least resistance here is to use jQuery

  • For mobile applications (iPhone, Android or Windows Phone 7) there are numerous ways to send, receive and consume JSON. For example, here, here and here

To REST or not to REST

A decision you may want to take at some point is whether to make your web services RESTful. The principles of REST are well documented but often misunderstood (some developers claim their web services are RESTful simply because they use "clean" urls). There isn't enough space here to begin explaining the philosophy of REST, I couldn't do the subject any justice and I'd likely get it wrong, however I do recommend obtaining a copy of RESTful Web Services published by O'Reilly Media. There are few questions on REST on this site that you may find worthwhile perusing.

Hopefully this answer will give you a jumping of point to get you started.

share|improve this answer
add comment

Web Services is much good approach to make communication between windows and web application.

you can start and learn very easily from MSDN website. Here are few links that will help you to learn Web Services from start/ scratch.

MSDN - Web Service - It have all information about various type of Web Service.
1. Simple Web Services
2. XML Web Services
3. WCF Web Services etc.

Create and Call Web Services - ASP.Net - Watch This Video to understand better that how to do all of this stuff.

A Step By Step Approach of Creating and Using an ASP.NET Web Service in Visual Web Developer will let you know that how to code for this.

Calling and consuming Web Services on .Net Platform is same for most the technologies. You have to add Web Service Reference in your project to consume them Either it is WPF application or Simple Windows Form Application.

  1. Open your project in Visual Studio. From the Project menu, click Add Web Reference.
  2. In the dialog box, set the URL to the following: http://services.msdn.microsoft.com/contentservices/contentservice.asmx?wsdl
  3. Press Go, then Add Reference, to create the web reference.

Check this Windows Presentation Foundation User Education - Binding to Web Services

For more information read O'really Programming .NET Web Services - Chapter 2 online.

Hope all of this will help to understand and implement Web Services in your application. There are lots of Questions on Stackoverflow regarding Web Services. May be you will utilize them.

share|improve this answer
add comment

Web services sounds like a great way to go. To get understanding I'd start with MSDN. After that, here are 3 great (albeit similar) tutorials on webservices. A simple Google search will bring up more. To help with the jargon, you will be providing a web service and the other applications will be consuming it.

share|improve this answer
add comment

Your Answer


