There are a lot of resources out there that explain the pros and cons of using one over the other. But what about what they actually are? I mean, at the most fundamental level? I researched a bit. This SO answer helped.
WCF and Web API
They are both hosted on a server, and both accept socket requests. The point is to accept messages and do something and possibly return something.
WCF
WCF replaced web services. It can be made to be restful, and it can be made to use SOAP. Hmmm, doesn't restful imply using HTTP GET and/or POST? And if it's restful, then our message protocol can be XML, JSON, plain text, etc. The point is that we're not tied to SOAP here. With SOAP, we're not tied to HTTP, so we can use protocols like TCP.
Web API
Web API uses HTTP. Period. So, what's the point, if WCF can be made to work this way as well? Perhaps it's because WCF needs to be made to fit the HTTP paradigm, and it's not natural, making it a bit of a pain to make it fit?
I've started by reading two good articles, here and here. The first thing I'd like to do is parse this excerpt from that first link:
There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services: services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer.
First, about non-SOAP services. I understand JSON being non-SOAP, but why is XML non-SOAP? Isn't SOAP really just XML? Perhaps SOAP is XML, but it's XML wrapped in a SOAP envelope, header and body. So, that's the difference? SOAP isn't only XML, it's XML inside SOAP.
What is the power of the HTTP protocol? Is is that we can use simple GET and POST requests, or is there more than that?
Understanding the Conclusions From the article mentioned above:
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF.
Why? Because HTTP GET and POST simply don't work that way?
If you want to create services 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 transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
It's not even an issue of being better off, right? I mean, if Web API is only HTTP, then we simply CANNOT use it for anything other than HTTP.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
Makes sense.
