Related
I have read many articles in the web so far, about the differences between WCF and ASP.Net web API. Unfortunately I could not come up to a clear idea about what will serve my purpose. Most of the Articles I have read highlighted on the design point of view of the two web services. But I am confused what will work best for my project and why? Here is my brief description of the project.
I need to create a communication channel between two servers (both are written in C#). The servers will communicate using messages (certain type of commands). The messages sometimes can be only acknowledgements, and sometimes the messages may contain instructions to do some computation. For example, one message can be draw something, or send an SMS etc. And not necessarily the messages will involve any database transactions. But the messages can sometimes send large text files as payload (around 1-5 MB maxm). What I believe WCF is very will surely do this, but can I do the same with ASP.net web API. Because so far all the example I have seen for ASP.Net web api: they are good for RESTful services that manipulate some kind of DB store (GET, PUT, DELETE). But in my case I will need to expose service points that will
do some kind of processing such as return the value of a computation, sending and acknowledging messages, etc.
Not just manipulating a DB-store.
So, what should be the best and simplest way to do so? It is needed to be mentioned that I did not find any straight forward example of achieving this using ASP.Net web API.
The Question you have asked is an overly-broad or primarily opinion-based, and its hard to give an example for what you have asked.
Important Points:
Firstly, if you are going to create a service which would be used on different platforms, then go with WCF.
Secondly, if you are creating internet service which is going to use external resource, then go with Web API.
Web API is the best choice if you are going to create a service for low bandwidth devices or mobile devices to access client.HTTP
request/response is also more readable as compared to SOAP because it
contains header, body, etc. which makes it complex.
Just take few minutes and read the below article, until you get complete understanding of few principles.
Original Source Can be found Here, Here and Here.
To whom choose between WCF or WEB API :
Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
Choose WCF when you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transport channels are unavailable.
Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iphone and tablets.
Why to choose Web API
Web API doesn't have tedious and extensive configuration like WCF REST service.
It is very simple, creating service with Web API. Where as With WCF REST, service creation is bit difficult (requires clear understanding of configurations).
Web API is only based on HTTP and HTTPS and easy to define, expose and consume in a REST-full way.
Web API is light weight architecture and good for devices which have limited bandwidth like smart phones.
My Opinion:
Simplest way to do so - Web API (Since you dont have any examples for this)
Hardest Way is (Configurations) - WCF (Better go with WCF, since you have examples)
I hope this gives you a clear idea about what to choose...
First things first, RESTful is a stateless and uniform interface norm that can be applied to web services. It doesn't have to be automatically and only plain old CRUD service backed by a DB.
In the real world, we can hardly say that all web REST API respect fully the norm, in fact they don't most of the time, especially the stateless part.
For your message based API, especially if it's bidirectional and event based, you can use websockets and consider the REST API a way to expose an uniform, stateless web interface to create those. And yes you can use websockets with ASP.NET WebApi there's plenty of tutorial out there, even for the newer ASP.NET Core.
The "between services" interactions part is no different than the usual Web browser <=> Web service, you're just using C# code instead of JS for the client.
I can hardly recommend WCF that uses SOAP since it's hardly portable considering the web standards nowadays. For instance if want to use a browser client instead of another ASP.NET service, well you'll have to do additional code client side to handle supports.
You can use WCF websockets, providing the almost all the advantages of WCF SOAP.
tl;dr :
You can mix RESTful and Websockets, it can actually be better than going full REST or full Websockets
It's personal preference to use SOAP over websockets but do comes with a potential technical debt considering what you want to do afterwards
Message API between services is no different than a message API between a service and a browser
WebAPI is not just good for RESTful webservices. You can easily send requests to a WebAPI controller and handle it the way you want : calculations, sending messages, interact with a CRM, interact with DB or anything else.
WCF was created to manage SOAP based webservices and brings extra complexity. It handles TCP, Mime...
If you just need to handle HTTP requests, the simplest way is to go with WebAPI.
I would suggest Web API if it is for RESTful services as WCF was never made to serve as Restful services although you can serve as one where as Web API was made particularly for this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've spent a few months trying to grasp the concepts behind WCF and recently I've developed my first WCF service application.
I've struggled quite a bit to understand all the settings in the config file.
I am not convinced about the environment but it seems that you can do amazing stuff with it.
The other day I've found out that Microsoft has come out with a new thing called ASP.NET Web API.
For what I can read it's a RESTful framework, very easy to use and implement.
Now, I am trying to figure out what are the main differences between the 2 frameworks and if I should try and convert my old WCF service application with the new API.
Could someone, please, help me to understand the differences and usage of each?
For us, WCF is used for SOAP and Web API for REST. I wish Web API supported SOAP too. We are not using advanced features of WCF. Here is comparison from MSDN:
The new ASP.NET Web API is a continuation of the previous WCF Web API project (although some of the concepts have changed).
WCF was originally created to enable SOAP-based services. For simpler RESTful or RPCish services (think clients like jQuery) ASP.NET Web API should be good choice.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
In the scenarios listed below you should go for WCF:
If you need to send data on protocols like TCP, MSMQ or MIME
If the consuming client just knows how to consume SOAP messages
WEB API is a framework for developing RESTful/HTTP services.
There are so many clients that do not understand SOAP like Browsers, HTML5, in those cases WEB APIs are a good choice.
HTTP services header specifies how to secure service, how to cache the information, type of the message body and HTTP body can specify any type of content like HTML not just XML as SOAP services.
Since using both till now, I have found many differences between WCF and Web API. Both technology stacks are suited well to different scenarios, so it is not possible to say which is better, this depends on configuration and scenario.
Properties ASP.Net Web API WCF
--------------------------------------------------------------------------------------------------
End point (mainly) Http based SOAP based
Service Type Front End Back-end
Support caching, compression, versioning No
Framework ASP.net WCF
Orientation Resource Oriented Service Oriented
Transports http http, tcp, MSMQ, Named pipe
Message pattern Request reply request Reply, one way, duplex
Configuration overhead Less Much
Security lesser than WCF (web standard security) Very high (WS-I standard)
Hosting IIS IIS, Windows Service, Self hosting
Performance Fast A bit slower than Web API
In use from .NET 4.0 .NET 3.5
Note: The data is not only my view, it is also collected from other official websites.
WCF will give you so much of out the box, it's not even comparable to anything. Unless you want to do on your own implementation of (to name a few) authentication, authorization, encryption, queuing, throttling, reliable messaging, logging, sessions and so on. WCF is not [only] web services; WCF is a development platform for SOA.
Why I'm answering:
I took huge amount of time to understand the difference between these two technologies. I'll put all those points here that I think "If I had these points at the time when I was wondering around in search of this answer, then I have decided very earlier in selecting my required technology."
Source of Information:
Microsoft® Visual Studio® 2015 Unleashed
ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3
Why ASP.NET Web API and WCF:
Before comparing the technologies of ASP.NET Web API and WCF, it is important to understand there are actually two styles/standards for creating web services: REST (Representational State Transfer) and SOAP/WSDL. The SOAP/WSDL was the original standard on which web services were built. However, it was difficult to use and had bulky message formats (like XML) that degraded performance. REST-based services quickly became the alternative. They are easier to write because they leverage the basic constructs of HTTP (GET, POST, PUT, DELETE) and typically use smaller message formats (like JSON). As a result, REST-based HTTP services are now the standard for writing services that strictly target the Web.
Let's define purpose of ASP.NET Web API
ASP.NET Web API is Microsoft’s technology for developing REST-based HTTP web services. (It long ago replaced Microsoft’s ASMX, which was based on SOAP/WSDL.) The Web API makes it easy to write robust services based on HTTP protocols that all browsers and native devices understand. This enables you to create services to support your application and call them from other web applications, tablets, mobile phones, PCs, and gaming consoles. The majority of applications written today to leverage the ever present Web connection use HTTP services in some way.
Let's now define purpose of WCF:
Communicating across the Internet is not always the most efficient means. For example, if both the client and the service exist on the same technology (or even the same machine), they can often negotiate a more efficient means to communicate (such as TCP/IP). Service developers found themselves making the same choices they were trying to avoid. They now would have to choose between creating efficient internal services and being able to have the broad access found over the Internet. And, if they had to support both, they might have to create multiple versions of their service or at least separate proxies for accessing their service. This is the problem Microsoft solved with WCF.
With WCF, you can create your service without concern for boundaries. You can then let WCF worry about running your service in the most efficient way, depending on the calling client. To manage this task, WCF uses the concept of endpoints. Your service might have multiple endpoints (configured at design time or after deployment). Each endpoint indicates how the service might support a calling client: over the Web, via remoting, through Microsoft Message Queuing (MSMQ), and more. WCF enables you to focus on creating your service functionality. It worries about how to most efficiently speak with calling clients. In this way, a single WCF service can efficiently support many different client types.
Example of WCF:
Consider the example:
The customer data is shared among the applications. Each application might be written on a different platform, and it might exist in a different location. You can extract the customer interface into a WCF service that provides common access to shared customer data. This centralizes the data, reduces duplication, eliminates synchronization, and simplifies management. In addition, by using WCF, you can configure the service endpoints to work in the way that makes sense to the calling client. Figure shows the example from before with centralized access of customer data in a WCF service.
Conclusion:
i) When to choose Web API:
There is no denying that REST-based HTTP services like those created using ASP.NET Web API have become the standard for building web services. These services offer an easy, straightforward approach for web developers building services. Web developers understand HTTP GET and POST and thus adapt well to these types of services. Therefore, if you are writing services strictly targeted to HTTP, ASP.NET Web API is the logical choice.
ii) When to choose WCF:
The WCF technology is useful when you need to support multiple service endpoints based on different protocols and message formats. Products like Microsoft BizTalk leverage WCF for creating robust services that can be used over the Web as well via different machine-to-machine configurations.If, however, you do need to write an application that communicates over TCP/IP when connected to the local network and works over HTTP when outside the network, WCF is your answer.
Be Warned:
Web developers often view WCF as more difficult and complex to develop against. Therefore, if you do not foresee the need for multiprotocol services, you would likely stick with ASP.NET Web API.
There is a comparison on MSDN about this
WCF and ASP.NET Web API
For me, the choice was about Who the clients are, and where are they located?
Within the company Network and .NET based clients : Use WCF with TCP binding (Fast communication than HTTP)
Outside the company Network, and use diverse technologies like PHP, Python etc: Use Web API with REST
Business speaking, WebApi lacks of a WSDL, so the developers should document all manually. And if, for example, the WebApi operation returns a list of objects then, the client should creates the objects manually, i.e. WebAPI is really prone to errors of definitions.
The pro of Webapi is its more lightweight than WCF.
Regarding the statement "WebApi lacks of WSDL" there are several ways to generate Rest client. One popular approach is Swagger UI / (Swashbukkle Nuget). This gives a rich interface to understand the REST end point's input and output schema and online tool to test the end points.
JSON LD (Json Linked Documents) is another emerging standard which will further improve the JSON based REST developer experience by exposing the JSON schema with better semantics.
With wcf we can configure and expose the same service support for multiple endpoints like tcp, http.if you want your service to be only http based then it will be better to go with web API. Web API has very less configuration when compared to wcf and is bit faster than wcf. Wcf also supports restful services. If you have limitation of .Net framework 3.5 then your option is wcf.
I've done a bit of work in the past using WCF WebAPI and really liked a lot of its features, I'm just playing with ASP.NET Web API at the moment and it seems completely different (IE completely removed from WCF).
Does anyone know which features of WCF WebAPI are included in ASP.NET 4 Web API?
Ive done a little more reading around this and found a few pages by MS people on this:
http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API :
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web API -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
and http://wcf.codeplex.com/discussions/319671
The integrated stack supports the following features:
Modern HTTP programming model
Full support for ASP.NET Routing
Content negotiation and custom formatters
Model binding and validation
Filters
Query composition
Easy to unit test
Improved Inversion of Control (IoC) via DependencyResolver
Code-based configuration
Self-host
From what I've learned, Microsoft did a little bit of naming confusion here.
I'm assuming you know what WCF is all about, this big framework built on top of XML to allow user to build distributed services with a wide variety of technologies (from SOAP to REST to MSMQ etc.).
It's hard as hell to use (for me at least) and requires a lot of bootstrap to have it working, and eventually they realized this and started providing some default configuration for simple http services (WCF REST starter kit anyone?). ASP.NET MVC was gaining momentum and some of the features it provided (automatic arguments matching for example) started to show up in WCF.
Now that's the situation:
Announcement: WCF Web API is now ASP.NET Web API! ASP.NET Web API
released with ASP.NET MVC 4 Beta. The WCF Web API and WCF support for
jQuery content on this site wll removed by the end of 2012.
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that's better imho.
I'm quite sure it should be possible to host asp.net mvc4 webapi on top of WCF (if you ever need that), but i can't find documentation that can prove me right (or wrong).
UPDATE (can't fit as comment):
Wait, there is a huge different between "moving a subset of communication technology from a library/framework to another" and "replace WCF". I personally think that WCF was designed for some kind of communication concept and it has a rather cool design, but the distributed computing is somewhat moving on to new (and simpler) solutions (look the feature-rich SOAP vs the lean e flexible REST, although many people still use REST in a RPC manner), and i think that this kind of programming patterns better fit into the MVC architecture than the WCF one. Effort was put on designing some simple way of building/consuming web services on top of WCF, but they eventually found out that it was not the right solution.
Not to mention that many developers now use ASP.NET MVC and want to do rest web services for their web app, messing with WCF is often overkill for these kind of things, and I've experienced that on my own skin.
I think that the routing mechanism is awesome and the right way to go, and if you look closely, they included part of it (with different names and types, but the pattern was there) in WCF. So yeah, i think that if MS don't dismiss that part of WCF WE should do it. To strictly answer, no, i don't think you'll ever find WebGet/WebInvoke in asp.net mvc*, it just don't fit in.
Yeah self-host is probably the only bit of WCF contained in ASP.NET MVC4 right now.
It looks like WCF itself is somehow dying or at least becoming much less important then it was supposed to be and because of that it also has much less development effort put into its feature set. New features in WCF itself are more cosmetic.
WCF was designed as transport / protocol independent way for inter process communication. Even the idea was independent abstraction it was mostly build on top of SOAP stack. When WCF 3.5 brought support for REST it was mostly hacked in because REST is all about transport dependency. Using transport independent API to support inter process communication which is done through directly using transport features appeared inconvenient. As result MS first released WCF Rest API Starter Kit which never reached RTM but it was preview of features which was later included in WCF 4 and finally in .NET 4.5 or WCF Web API. Because REST is transport dependent and currently used only with HTTP (even it is theoretically possible to use other transport protocol) the API was moved to .NET part which is more suitable for HTTP processing - to currently very popular ASP.NET MVC.
WCF Web API is replaced by ASP.NET Web API which takes features from WCF Web API and merges them with the features from ASPNet MVC. ASP.NET Web API is a new (02/2012) framework for building and consuming HTTP services and a platform for building RESTful service.
Although not in the original question it seems worth noting that WCF is alive and well and its REST support remains useful when you have existing SOAP (WS-*) services you must support but want to add REST to reach more clients.
Reference
CodePlex: WCF Web API is now ASP.NET Web API
CodePlex: Daniel Roth on the Future of WCF
Chanel9: Dan Roth on the new ASP.NET Web API
The following excerpt found on this MSDN page summarizes this dilemma well.
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.
Here is good article on Web Service, WCF and Web API http://goo.gl/T29A5B
Web Service
Based on SOAP and return XML Data
Support only HTTP protocol. It support only HTTP protocol.
Consumed by client that able to understand xml SOAP Services.
Can host on IIS. It can be hosted only on IIS.
Easy to Learn and understand.
WCF
Based on SOAP and return XML Data. SOAP is heavy compare then JSON and its overhead over network also.
Enhanced version of web services support multiple protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ via configuration.
More reliable when both client and server have .Net.
Its implementation and configuration is complex
Consumed by client that able to understand xml SOAP Services.
Self-hosting, IIS and using windows services.
Web API (Web API 2.0)
Design specifically for building HTTP Restful Services on .Net Framework.
Web API easily readable and handy as JSON.
Support all features of HTTP Like URls, Request/Response, Headers, Caching and Versioning.
Web API support many HTTP Verbs like GET, POST, PUT, DELETE etc.
Web API is stateless.
Web API supports MVC features (controllers, action results, routing, filter, model binders, IOC container or dependency injection)
Web API can be self-hosted, hosted with in the application and on IIS.
OWIN (Open Web Interface for .NET) is used for self-Hosting.
ASP.net web api is lightweight and REST support inbuilt. It is more suitable for mobile applications.WCF is bloated with more options . It depends on the complexity of the system to select one of these.
I am thinking to start writing some REST web services as a way to provide data. I guess that when my REST web services are available, then some of my web applications and console applications will be able to use REST web service as data service to get, add, update and delete data to databases. In addition to that, I would like to add authentication feature to identify any request.
My question is that where should I start? I saw Microsoft ADO.Net Data Services. Not sure if this is a good start place? Are there any examples available?
Check out the REST in WCF MSDN site and the starter kit. Good article here too.
You may also want to check out servicestack.net An Open Source, cross-platform, high-performance web service framework that lets you develop web services using code-first, strongly-typed DTO's which will automatically (without any configuration) be immediately available on a variety of different endpoints out-of-the-box (i.e. XML, JSON, JSV, SOAP 1.1/1.2).
REST, RPC and SOAP out of the box
In addition, your same web services can also be made available via any ReST-ful url of your choice where the preferred serialization format can be specified by your REST client i.e.
Using the HTTP Accept: header
Appending the preferred format to the query string e.g. ?format=xml
See the Nothing but REST! web service example for how to develop a complete REST-ful Ajax CRUD app with only 1 page of jQuery and 1 page of C#.
A good place to start is the Hello World example to see how to easily add ServiceStack web services to any existing ASP.NET web application.
Performance
For the performance conscience, ServiceStack makes an excellent Ajax server as it comes bundled with the fastest JSON Serializer for .NET (> 3x faster than other JSON Serializers).
Checkout this live Ajax app for a taste (Live demo hosted on Linux/Nginx/MONO).
Simple Northwind Example
ServiceStack also makes it easy to create strong-typed frictionless web services where with just the code below is all you need to return a List of Customer POCOs:
public class CustomersService : RestServiceBase<Customers>
{
public IDbConnectionFactory DbFactory { get; set; }
public override object OnGet(Customers request)
{
return new CustomersResponse { Customers = DbFactory.Exec(dbCmd =>
dbCmd.Select<Customer>())
};
}
With no other config, you can now call the above webservice REST-fully returning all of:
XML
JSON
CSV
HTML
JSV
SOAP
Accessing web services on the client
You can call the above web service re-using the same DTOs that your web services were defined with (i.e. no code-gen is required) using your preferred generic ServiceClient (i.e Json, Xml, etc). This allows you to call your web services using a strong-typed API with just 1 Line of code:
C# Sync Example
IServiceClient client = new JsonServiceClient("http://host/service");
var customers = client.Send<CustomersResponse>(new Customers());
And since your web services are also REST services, it works seamlessly with JavaScript ajax clients, e.g:
Using jQuery
$.getJSON("http://host/service", function(r) { alert(r.Customers.length); });
ASP.NET Web API is now the Microsoft framework for creating RESTful services.
http://www.asp.net/web-api
If you are new to REST in the .net world then start with OpenRasta. The other Microsoft solutions can do REST if you work hard at it but they will guide you down a route where you will most likely end up with POD(Plain old data) over HTTP. That is not what REST is all about. If that's all you want then that's cool too, but it is not REST.
If you're going WCF, the WCF REST Starter Kit that JP referred to is a great place to start.
Omar Al Zabir provides a pretty good example of using ASP.NET MVC to provide RESTful services that are fluent in both XML and JSON
You can also go the ADO.NET Data Services route you suggested. These services are built on top of the WCF stack.
I've never stumbled across any really good guidance on how to select between these options. In ASP.NET MVC you take on the majority of the plumbing burden but also have maximal control. Straight RESTful WCF is the happy middle ground although WCF tends to want to have things done its way. ADO.NET Data Services are pretty magical with the downside of buying fully into a given approach to generating these services and losing more flexibility.
There are a couple of good books you can read on the topic of RESTful services with .NET. Both O'Reilly and Microsoft Press have recently released books on this topic. Perhaps the most important advice I can provide you is to consume and understand several open RESTful services (e.g. Twitter, Amazon, Flickr) to understand the design decisions that went into creating the services. User provisioning, authentication mechanism, and supported content types (e.g. JSON, XML, RSS/ATOM) are some of the decisions that you can observe in action to aid you in your path to creating your service API.
I would like to access to multiple web services with a WPF application (Facebook, Twitter, etc...).
I'm not familiar at all with WCF and I was wondering what should I use and why (pros and cons) ? WCF or something else more traditional (like HttpWebRequest) ?
Go with WCF! It's the way to go, it's the present and future of Microsoft's "connected systems" strategy. You can attach to just about anything using WCF - and contrary to Khalid, I don't think it has a really high learning curve.
Get yourself a good book - I recommend Learning WCF by Michele Leroux Bustamante - check out her samples, play with those.
Also check out online resources:
WCF Developer Center on MSDN with tons of articles, screen casts etc.
Dotnet Rocks TV: Keith Elder Demystifies WCF
Dotnet Rocks TV: Miguel Castro's Extreme WCF
That should easily get you started! There's a ton more stuff out there.
Watch those two DNR-TV screen casts - they show how to really understand what is needed in terms of WCF configuration. It's really not rocket science! But unfortunately, the "Add Service Reference" and svcutil.exe both have a tendency to create awfully and overly complicated configs - that's not necessary.
More online resources for WCF REST and Twitter:
MSDN Developer Center for WCF REST
Pluralsight Screencast library on WCF REST
Screencast: Using HttpClient to consume Twitter in under 3 minutes
Why be "traditional" when you can get WCF to do some of the work for you?
If you're accessing a number of services, you'll be writing a lot of duplicate code. You might then refactor the duplication into a framework for calling the services.
WCF already is such a framework, so why write your own?
I've developed with both WCF and straight web requests.
WCF can be great when developing web services, but there is no guarantee that all third party services will be implementing a protocol that works with WCF (add service reference or svcutil).
Also WCF has the advantage of being hosted anywhere you want, like Console, Web site, WPF application, or Windows Service. When it comes to configuration there is a high learning curve with WCF, so understand that going in.
More and more third party services are adopting a REST interface. This means most of your calls out will be done using the HttpWebRequest. Once you make the call to the service, you will have the issue of deserializing the data coming back (XML, JSON, Key/Value Pair, Fixed Length). If it is XML or JSon, look into using the XmlSerializer or DataContractSerializer.
So if you are writing your own web service (calls coming in), go ahead and use WCF. If you are consuming a web service (calling out to a service i.e. Twitter) you most likely won't have the choice to use WCF.