Deciding between WCF/SOAP or Rest for a new project

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?
Marc VBAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Gary DavisDir Internet SvcsCommented:
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
Marc VBAuthor Commented:
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?
käµfm³d 👽Commented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.