Deciding between WCF/SOAP or Rest for a new project

Posted on 2014-08-08
Last Modified: 2016-02-26
I'm going to create a new project for a web service. I've done SOAP before and always found it working great; especially because it has typed objects/fields and contracts. I like the structured approach. Today you're considered a "fool" if you don't use Rest as this is the new popular thing.

What do you think? Are there compelling reasons for not using WCF/SOAP at all for a new project?
Question by:Marc VB
    LVL 18

    Expert Comment

    by:Gary Davis
    I do like the old Soap web services because of the strongly typed request/response objects automatically built, including the proxy page for testing and documentation.

    WCF is a little harder but you get the strongly typed objects but no proxy page. It is testable and configuration may be a bit of a challenge.

    Web Api's are the latest but you do lose out the Soap advantages. You can build your own model for the request and response objects and there is a Firefox add-in testing client that I find helpful. This may be the best way to go since it is the future and clients will be able to easily call your service. There is a help page you can build out that will allow your users to see example request and response JSON, etc.

    As with everything like this, the real answer is that all will work and for the choice, "it depends".

    Gary Davis

    Author Comment

    by:Marc VB
    At first sight WCF services seems to be as easy to create as SOAP services in Visual Studio; or am I overseeing something?

    Is there any disadvantage in creating a SOAP service now (in 2013)? In my profession I still see quite a number of companies using SOAP. I personally don't care if something is old or new; if it works it works (...).

    What confuses me is that I've read in a book (Murach ASP.NET) that a client needs .NET to consume WCF services? This can't be true it it?
    LVL 74

    Accepted Solution

    What confuses me is that I've read in a book (Murach ASP.NET) that a client needs .NET to consume WCF services? This can't be true it it?
    WCF is more than just SOAP. It's a whole framework dedicated to, well, communication. WCF deals in SOAP, TCP/IP, pipes, and a few others. For some of those "exotic" messaging types, yes you will need .NET due to the serialization that is involved. The whole point of SOAP is to define a protocol for transferring messages between disparate systems. A system that understands SOAP should have no trouble communicating with a WCF service that exposes a SOAP endpoint.

    As to which you should use, I'll admit that the whole building of DTO classes by WCF is nice, and the "Add Service Reference" functionality is practically icing on the cake when you are building clients, but keep in mind that WCF is quite massive. In my opinion, WCF is one of those things that one the surface, if there are no problems, then life is great:  You have classes already built, your service can be up in running in short order, and you can expose the different messaging options just by adding in config file settings. However, when things go wrong...  they go really wrong. Because WCF is so massive, often times trying to figure out what exactly is broken can be a royal pain in the [choice word here]. Also, SOAP messages are very heavy. XML itself is a heavyweight language; adding in SOAP just expands the amount of cruft going out over the wire.

    The hot term right now is REST(ful). RESTful services take advantage of the way that the Web actually works, and so things tend to be a lot simpler to understand, at least in how the messages are formed and transmitted. REST is what Web API offers. While it is true that you don't get the buttery goodness of the pre-built DTOs and "Add Service Reference," you do get a simpler messaging package, and it is--again in my opinion--easier to figure out where things are breaking. Also, you are free to change how you package up the data in the response. You can easily swap out JSON for XML for plain text for etc. In SOAP, sure you could package some JSON up inside your envelope, but your still within and XML document. You can really cut down the size of your messages by swapping out the type of serialization you perform. Heck, you could even use Google's Protocol Buffers. We actually have a Web API service at my job where just by swapping out the "Accept" HTTP header you can get back XML or a PDF.

    I believe there are some projects being worked on out in the wild that will actually do a similar thing to "Add Service Reference" for RESTful services.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    What Should I Do With This Threat Intelligence?

    Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

    For a while now I'v been searching for a circular progress control, much like the one you get when first starting your Silverlight application. I found a couple that were written in WPF and there were a few written in Silverlight, but all appeared o…
    Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
    This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA.…
    Migrating to Microsoft Office 365 is becoming increasingly popular for organizations both large and small. If you have made the leap to Microsoft’s cloud platform, you know that you will need to create a corporate email signature for your Office 365…

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now