We Keep Coding

Salesforce SOAP vs REST

I have been building a console app the uses the Saleforce SOAP API, and now need to use the Salesforce API in a web app.
Am I correct to assume that SOAP is better suited for a non web-based app, and REST is better for a web app?
If I where to create a wrapper that would be used in either reporting from local apps, or posting to salesforce from our websites, should I expose both the REST and SOAP api's, depending on what the app is? Or should I just stick to using one? What are deciding factors I should look at if I just need to pick one?

The other answers contain some good general info, some salesforce specific things to take into account are
1) You can directly bulk update data in the SOAP API, but you'll need to use the Async Bulk API to do that from REST.
2) The soap API contains a few things not available in the REST API, most notably describeLayout, queryAll, getDeleted & getUpdated
3) the REST API contains a few things not available in the SOAP API, including the API for chatter, and access to the recently accessed records lists.
4) the REST API can access binary data (files, attachments, content, etc) without the overhead of base64 encoding/decoding.
So, depending on exactly what your app is trying to do may push you one way or the other.

I believe it ends up being personal preference if you're consuming it by a .NET application, regardless of whether it's a web app or not.
Personally, I would go with SOAP as .NET has a lot of built in functionality to consume a SOAP service, it builds all the method prototypes for you and will make development faster than you handcrafting REST requests yourself. .NET will take care of the marshalling of SOAP.
As for building a wrapper, you have to consider your target audience, if your target audience is other .NET application developers, then exposing your own WCF service might be a decent option, WCF also has endpoints for either SOAP or REST.

IMHO, if you are developing the solution from .NET as your question indicates, SOAP is the way to go. REST services are beneficial because they lack the bulk and tool set requirements that surround SOAP and are nice for the bootstrap developer without access to heavy investment tools like .NET. I agree with the other comments that REST more closely mirrors the underlying HTTP methodology, and is easier to read and parse explicitly, but that isn't really something you have to concern yourself with from within a tool like VS and .NET.
Additionally, since you have existing console apps that may be brought into the communication mix at some point, it might be good to have the WCF flexibility to be transport agnostic and not tied to HTTP as you would be with REST.
So I really don't think you are in a position to take advantage of the REST advantages or be impacted by the shortcomings of SOAP, so it makes sense to go with the heavily standardized option that fits best into your existing tool set.

The decision to use REST or SOAP when both are available is usually related to:
The tools and language you're using for your application
Your familiarity with either style
The performance needs of your application (JSON payloads are smaller than XML payloads)
If the 'local' apps are calling the services from the server side, then all else being equal, you can at least generate C# code directly from the WSDL and that makes using the SOAP API simpler (no hand coding).
If the web application needs to call the API directly from the client side (browser), then use REST and work with JSON. This will be far simpler. You wouldn't be able to reuse the same wrapper regardless, so no problem using two different APIs other than the time it takes to learn them.
If the web app usage of the API is on the server (not client) side, then definitely target just a single API. WSDL if you want to auto-generate the code to call it, REST otherwise for simplicity and efficiency.

IMO, SOAP was a standard created as a contract type messaging architect, I.e. When passing messages just use this "contract." It was generic enough that it doesn't embrace any particular technology.
REST is a actual methodology that embraces HTTP, it is a way of utilizing GET, POST, PUT and DELETE to it's max potential.
I wouldn't assume one is better then the other, what it really boils down to is using the right tool for the job. I wouldn't make a distinction between web-based app and non web-based. Because SOAP or REST can be beneficial to both.
Here are a few questions I would get answered first:
1) Who is my target client. Microsoft Workshop Client, Java, PHP type.
2) What types of (Lack of a better term.) "Endpoints" do I want to expose to my Api. (JSON, XML, Ajax, POX or all of the above.)
3) What will my clients be going with this API? Do they already have clients that are based on SOAP. If so, SOAP is the way to go.
4) REST will makes you think about your URL design and thus allowing a client to "mashup" data to build what they need. So if you think that's something you want. REST is the way to go.
5) REST makes use of the "GET" in HTTP, this allows a client to cache results. "Conditional GET is what it's called. It allows them to cache a big object, ask the server via just a header (small) if the last update matches what is cached, if so. don't bother with a full object GET, what is cached is the latest version. This can be done in SOAP, but out of the box, REST is better for this.
Anyway, hopefully that gives you the better data, so you can make the better decision. And if all else fails you can just do both. But then you'll have to deal with trying to get two types of services (different methodologies) and one codebase for both. (can be tricky, but not that difficult.)
Personally. I would pick one, then if you ever need the other, burn that bridge and pay the technical debt for it.

Late to this party, but just a quick note:
The Salesforce API isn't completely RESTful: I would call it REST-ish. It has SQL-like queries in URLs for some of its REST interface, that sort of thing.

SOAP API:
What is it for? Integrating your organization’s data with other applications using SOAP.
When to use it? You have pre-existing middleware services that need to work with WSDLs and XML data.
Protocol SOAP/WSDL
Data format XML
Communication Synchronous
REST API:
What is it for? Accessing objects in your organization using REST.
When to use it? You want to leverage the REST architecture to integrate with your organization.
No WSDL requirement.
Well-suited for browser-based applications, mobile apps, and highly-interactive social applications.
Protocol REST
Data format JSON, XML
Communication Synchronous

Should I use a REST based service to connect a C# and java (or other technology) through an API?

We are creating an API that suits the benefits of a REST based architecture. However where I struggle is in how easy it is to consume from different technologies.
Its a c# WCF service and if consuming via c# is a doddle, 1) give the dll with the contract to the calling project 2) use the WebChannelFactory generic to wrap the contract before calling the url and method.
However given this is an API I want other non .net based systems to be able to interract with it. The argument I hear is that why should developers read all the documentation for the REST based service, manually create a http request (in their language of choice), and then parse the response. When if we created a web service using SOAP all they would have to do is add a reference to it and let their technology of coice build the call and response objects for dealing with the SOAP and make the call using a few lines of code (I know its this easy in c# and apparently java is easy too).
Seems like from a consumption perspective from differing technologies that support SOAP and building references from WSDL's that SOAP wins hands down. But I really want to use REST just have this argument and I cant really argue with it.

I have only ever seen one argument for SOAP in favor of REST that I completely agree with, and your question makes it: Use SOAP if that is what the client/customer/user wants. If it really is the case that all of the consumers of this service can more easily use SOAP, then you should go with that.
Of course, if you want to support a client platform that does not have built-in support for SOAP, that could be another matter. You don't want your client/customer/user building a SOAP client layer from scratch, unless you just really don't like them.

I also definitly recommend using SOAP for such a purpose.
You already mentioned most of the benefits for SOAP against REST.
Why do you even really want to create a REST service if all facts point you to SOAP?
For me REST only has the advantage of faster access, but in most use cases its not that much that it would justify not to use the advantages of SOAP.
BTW: If you create a normal .net WebService you get both "for free", because they support SOAP and REST by default (maybe you need to enable on ore another in the web.config).

The reverse argument is that SOAP only works on platforms that have a WSDL parser and SOAP stack in place. Without one it's completely impractical to ever use it, whereas REST can be boiled down to "send HTTP request, parse results as XML".
Yes, for certain types of APIs on platforms that support it SOAP will be easier to work with. And in other cases its not. :) It really depends on what you're trying to do.
In WCF it's not terribly hard to enable both, so it might be worth it to do that and let the people using your API choose what they want to work with.

It sounds like what you're struggling with is that the industry is tending to move away from SOAP based services in favor of REST, but the tools for consuming such services are lagging.
One benefit of developing your service with WCF is that you abstract the endpoints (SOAP, REST, etc) from the actual application. Therefore, it seems premature to rule out SOAP or REST.
An approach might be to make your service by defining sound objects that you would like to expose for consumption. Once you've developed this, start trying to consume the service from different platforms/tools. You may learn that consuming a REST service is not as difficult as you might think. However, you may also learn that you simply do not need REST at the moment, but always have the option to turn it on if need be.

From what you've described, REST is your best option.
Here's something to consider:
There're several standards using SOAP, MS promotes WS-I Basic Profile 1.1 which is not so widely supported outside of MS world and people could easily have troubles connecting to your service.
REST have many advantages over SOAP just by utilizing HTTP (testing, caching, etc.). Although if you need complex security or messaging, REST won't support this out-of-the-box.
Using REST-services is really easy from anywhere, without any framework or tools.

Non-enterprise uses for WCF?

I'm interested in gaining a better understanding of WCF.
Of course, I can read books and tutorials about it, but it seems that a better way would be to actually come up with some project idea (either open-source or a startup) which would actually benefit from using WCF, and then build it using WCF.
What are your ideas for small-scale projects which might benefit from WCF?

I'm not sure it is really a matter of scale that drives a decision to use WCF. If a learning project is all you are interested in, then take a normal idea for a project, and turn the entire data access layer into WCF calls.
This should give you a fair understanding of all the little nooks and crannies of WCF, and allow you to fail in a controlled manner. That way you can make decisions in the future about when are where it is best to apply a service boundary using WCF.
As was already mentioned, anything to do with the web can benefit tremendously from WCF. Heck, you could build a pure JavaScript and HTML 5 application using WCF without ever touching ASP.Net.

A hosted service that a mobile device (such as a WP7 or iPhone) could connect with to retrieve data

WCF is great for setting up non-ASPX endpoints for Ajax clients. See for example this article. There are many more out there.

Any project involving .NET and communication is likely to benefit from WCF. WCF is the replacement for ASMX web services and for .NET Remoting. There's no one particular type of application that it is suited for. For instance, it's not like it's suitable for Enterprise applications but not for small ones.

WCF data contracts are very easy and handy for storing application configuration, settings and state. Write a library/application to take care of serialisation and editing.

PHP + .Net Web services for data access - Bad Design Choice?

The company has a PHP app that is in horrible condition. They want to start making plans to redesign it in .NET, however they need to run with the current design because of various reasons that I won't get into here.
They want to make some enhancements to the current design but do it in such a way that those enhancements can be in-part reused by their .NET version when it comes along. One idea to do this was to make the data and business logic portion of the app reside as a .NET webservice that would be consumed by the PHP end.
My question is will this cause problems in PHP? Can PHP consume .NET web services quickly and efficiently? Or is this just a bad design decision?

My question is will this cause
problems in PHP? Can PHP consume .NET
web services quickly and efficiently?
Or is this just a bad design decision?
I have two thoughts here. First to answer your question directly. I don't believe it's a bad design and if the .NET services are written language agnostic then there should be little issue.
The second thought is a "hope". I hope the choice to go with a .NET framework was not due to poorly written PHP. Changing languages because of poor implementation in my opinion is where the design fails. There will be more effort converting to a new language than there would be if the company choose to re-write the PHP and the end result would be a single unified language base with built-in legacy support. But then I'm a PHP fan.

For PHP to consume .NET webservices quickly you'll need to use PHP5 native SOAP Client API, enabling cache to store WSDL locally. If you use PHP4 you can use Nusoap, but it isn't as fast as native classes.

The whole point of having a webservice is interoperability between various development platforms. For instance twitter is a rails-based website and its services are consumed by multitude of various desktop and web applications written in .NET, java, python, etc, through its RESTful web-api. Facebook is PHP and C++ based as far as I know and how many webapps consume it's services through api. SO I don't think it's a bad idea. The question is how you implement this webservice. Meaning, do you want to use it once and then get rid of it or sue it for a long time. If the second option is true - make sure you design your webservice api with that in mind. Also PHP can easily consume XML-RPC and SOAP. I used both ( provided by a Perl based service) without any problem or big hits on performance.
I think using .NET to migrate from PHP is not the smartest choice - but that is somewhat subjective opinion. In my experience it almost always ended being an overkill, badly designed, more expensive to maintain and more buggy - because of the nature of the beast.
P.S.:
I'm not a PHP fan, but I don't believe in converting to .NET for the sake of converting. Also .NET infrastructure is more expensive to maintain and much more labor intensive.

The primary advantage of a webservice is its interoperability, or ability to be consumed by others independent of language. PHP should have something that allows it to consume webservices so that shou;dn't be too big of a deal. The disadvantage will be that it may be a little slower, but this is something you'd have to test out to see how much of an impact that has on your overall solution. Generally most solutions aren't inherently right or wrong, you have to test their usefulness to your particular circumstance.

PHP can consume .NET web services fine, as long as you stay away from WSHTTP based web services and use BASIC HTTP. You can secure BASIC HTTP web services with SSL for security.
WHen you are in Visual Studio 2008, and you have an ASP.NET (could be MVC or not, doesn't matter) project open, right click on the project and select "Add New Item." You will see see something under Web, called Web Service. This will create a .asmx file and you can find tutorials on how to create these basic web services.
Another alternative is to use Windows Communication Foundation, which has a lot of helpful classes, but it can be more complicated. The default configuration for a WCF service is WSHTTP, but it is possible to make a BASIC HTTP web service with the WCF too.

Not really much of a problem at all, just investigate your options.
Web Services can output data in a wide variety of formats. SOAP/XML are the default but there is no reason why you can't do YML, Xml serialized objects, or my current favorite JSON (which makes calling into it from a browser really easy).
Look also into WCF services, I believe they're supposed to supplant the Web Service format.
Finally, if you're looking for best practices check out Service Oriented Architecture. Its a large and varied field and this is exactly the sort of things they talk about.

What am I missing about WCF?

I've been developing in MS technologies for longer than I care to remember at this stage. When .NET arrived on the scene I thought they hit the nail on the head and with each iteration and version I thought their technologies were getting stronger and stronger and looked forward to each release.
However, having had to work with WCF for the last year I must say I found the technology very difficult to work with and understand. Initially it's quite appealing but when you start getting into the guts of it, configuration is a nightmare, having to override behaviours for message sizes, number of objects contained in a messages, the complexity of the security model, disposing of proxies when faulted and finally moving back to defining interfaces in code rather than in XML.
It just does not work out of the box and I think it should. We found all of the above issues while either testing ourselves or else when our products were out on site.
I do understand the rationale behind it all, but surely they could have come up with simpler implementation mechanism.
I suppose what I'm asking is,
Am I looking at WCF the wrong way?
What strengths does it have over the
alternatives?
Under what circumstances should I
choose to use WCF?
OK Folks, Sorry about the delay in responding, work does have a nasty habit of get in the way sometimes :)
Some clarifications
My main paint point with WCF I suppose falls down into the following areas
While it does work out of the box, your left with some major surprises under the hood. As pointed out above basic things are restricted until they are overridden
Size of string than can be passed can't be over 8K
Number of objects that can be passed in a single message is restricted
Proxies not automatically recovering from failures
The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembly, but it's full of rubbish and certain code generators choke on it.
I know the world moves on, I've moved on a number of times over the last (ahem 22 years I've been developing) and am actively using WCF, so don't get me wrong, I do understand what it's for and where it's heading.
I just think there should be simpler configuration/deployment options available, easier set-up and better management for configuration (SQL config provider maybe, rather than just the web.config/app.config files).

I use WCF all the time now and I share your pain. It seems like it was grossly over-engineered, but we are going to be stuck with it for a long, long time so I'm trying to learn it.
One thing I am certain about, XML sucks. I've had nothing but problems using XML to control it and have since switched to handling everything via code.

The concerns you listed were:
Size of string than can be passed can't be over 8K
Number of objects that can be passed in a single message is restricted
Proxies not automatically recovering from failures
The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembly, but it's full of rubbish and certain code generators choke on it.
here's my take:
(1) addressed a valid concern that customers had with ASMX. It was too wide-open, with no way to easily control it. The 8k limit is easily lifted if you know where to look. I guess you can count that as a surprise, but it's more of a one-time thing. Once you know about it, you can lift it and be done with it forever, if you choose.
(2) is also configurable.
(3) is known, but there are boilerplate ways to work around this. The StockTrader code for example, demonstrates a proven pattern. You can re-use the code in your own app. Not sure if this is fixed in WCF for .NET 4.0. I know it was an open request.
(4) The config is a beast. This is a concern for a lot of people. The problem here is that WCF is so flexible, and config of all of that flexibility is exposed through xml files. It can be overwhelming. An approach that seems to work is to take it in small bites, as you need it.
(5) I don't understand.

I vastly prefer ASP.NET MVC and Web API over WCF. If I had to summarize WCF to a developer who was just being introduced to it, I would say, "WCF is a well-meaning attempt to replace over-engineered, Java EE style RPC development." Unfortunately, many of the decisions made require you to become an expert in configuring low level, unimportant items (message sizes, timeouts, uninteresting protocol elements, etc.) while abstracting absolutely critical pieces (URL design, parameter serialization, response serialization, etc.). The difference in productivity and aggravation between teams I know using WCF vs. Web API is night and day.
To come clean a little: I have always hated the core concept of .NET Remoting. I feel that developers need a thorough understanding of the resource structure of their application and how these resources are serialized. Furthermore, the use of the "POST" verb for simple data retrieval is worrisome in a read heavy application that needs to scale.

I'll address the rest of your issues after clarification. In the meantime, I can address your question on when you should choose to use WCF: always.
WCF is the replacement for the old ASMX technologies, including WSE. It is also the replacement for .NET Remoting. It is the only technology upon which high-level communications features in .NET will be based for the forseeable future.
For example, consider Windows Azure. It was not inevitable that the new concept of "cloud computing" would have its communications aspects covered by WCF. Yet, WCF was flexible enough to be extended to cover those cases, with very little change in code.
If you're having trouble with WCF, then you'd do well to make sure Microsoft knows about it. WCF is the present and future of web service and other service-oriented development in .NET, so they've got a very strong incentive to listen to you and resolve your pain points. Either contact them directly through Connect, or ask questions here on SO (tag with WCF, please), and a lot of people will help you.

Biggest advantage of using WCF from a programmer's point of view: separates the definition of exposed services (operations, contracts, etc.) from the protocol's specific details, unlike ASMX where you expose a class as a web service directly in the code using attributes. Using a real example of mine: we where able to easily switch the transport protocol between web services and named pipes, whatever suited better the deployment and performance needs, without changing a line of code.

WCF is intended to SOA methodologies. Work professionally using it is a nightmare. I delivered a SOA solution using WCF as tool and hell, hundreds configurations and hidden tips! My past distributed solution using old style Web Services and Remoting were more stable. I've spent days working out the solution for the error "The underlying connection was closed: An unexpected error occurred" which makes no sense to happen for one method among 4 in the same contract. I'm very disappointed. It took me back through time where .net was first introduced with lots of promises and when we got hands on, hell, log problems came up!

To address the problem of maintenance nightmare of application config, some standard like UDDI or WS-Discovery exist, WS-Discovery will be supported by WCF in .NET 4.0.
Keeping the configuration of the
interfaces in code rather than moving
to explicitly defined interfaces in
XML, which can be published and
consumed by almost anything. I know we
can export the XML from the assembley,
but it's full of rubbish and certain
code generators choke on it.
Can you be more explicit ? I think you are talking about service behavior configured in code.
You can easily code behavior extensions to configure what your are talking about in config file instead of code BUT I think that if microsoft didn't do that there is a good reason.
For example a service with this behavior :
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)]
The implementation knows that the instance is not shared between multiple thread so it's developed differently than :
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]
In this case the service implementation should take care about concurency problems.
The implementation is coupled with the attribute ServiceBehavior, so moving this behavior in a XML file is not a good idea.
What if you can change a InstanceContextMode.PerCall service to a InstanceContextMode.Single service inside the config file ? You break the application !

Looking at how you mention XML and SQL, you are using WCF to build a web application or an actual web service (service on the Web, and not just SOAP exchange).
It helps thinking about WCF as a replacement for .NET Remoting (or DCOM, CORBA etc), which also happens to support web services as one of the transports. Interfaces declared in assemblies, behavior of proxies, certain configuration options and other aspects of the framework that look unnatural and complicated from perspective of web apps - actually do work out of the box for DCOM-style systems of distributed objects.
To answer the question: no, you are not missing anything and using WCF for web applications is complicated, because WCF is not a framework for building web applications. Probably such framework can be built on top of it, but I would hate to see WCF itself changed to move into web realm.