I think the discussion for programmatic service oriented usage vs human interaction is clear.
But if I were to create an application that makes use of both a programmatic API and a website that makes use of the data connected by the same API, does it lean the favour towards using only ASP.NET?
How easy is it to integrate ASP.NET and WCF to work on the same application?
As far as writing one application that leverages both ASP.NET/MVC and WCF, its not great. WebAPI may have improved matters, but in one project I am familiar with that was using WCF and MVC in the same app, they ended up maintaining two different sets of models to represent the same concepts - one for the WCF code and one for the MVC code. You can imagine all the mappers they had to write to translate things between the two models - there were lots of lines of code there that could have / should have been avoided.
Part of why this happened is that WCF request and response objects should be annotated with [DataContract] and their properties with [DataMember], while MVC does not require this. Idiomatic MVC on the other hand is going to want ViewModels, which have different goals than WCF DataContracts. Of course, its possible that the use of two full sets of domain objects had more to do with Conway's law than WCF & MVC conflicting, but it's worth pointing out that WCF and MVC have different goals and requirements as far as output and input.
Personally, I'm partial to developing a simple but powerful services oriented back end API, particularly when you might want multiple clients. I think the advent of excellent JavaScript MVVM and micro- MVC frameworks makes this a natural choice, as writing application code using BackboneJS, KnockoutJS and others allows for a capable development environment. You can then consume the back end in the micro MVC of your choice to build your web app, or on a mobile client, and your partners might consume the same API remotely as well.
Suggestion
Either WebAPI or Service Stack might be good candidates for building your back end API. I recommend Service Stack, as I've been using it for the last few months and have found it to be an excellent replacement to WCF. I'm currently writing a tutorial series on service stack on my blog.
The group maintaining service stack has posted an example application using the framework to develop a StackOverflow like clone which shows a development pattern that I believe is especially compelling. It involves a simple, model based services back end that you could imagine being consumed by an MVC website, a mobile app, or just about anything else easily. ServiceStack's design goals clearly encourage a pattern that should lead to less coupling between client and server. The idea is to avoid chatty API's with calls like GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm) in favor of fewer methods. You might implement the same thing in service stack like this:
[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers
{
public int? RegionId { get; set; }
public string SearchTerm { get; set; }
}
public class CustomersService : Service
{
public object Get(Customers request) {
// handle request
return new CustomersResponse();
}
}
The benefit, to my eyes, is that instead of having your business logic spread out over lots and lots of separate methods GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), it's all in one place. This should lead to more maintainable code.
Coincidentally, Stack Exchange hired the original Service Stack author. He continues to commit actively to the Service Stack project.
I am particularly fond of message queues for certain things - and while WCF allowed for this, WebAPI does not. ServiceStack does allow the same web service to be invoked via MQ. For more info on this see the Redis MQ Host at: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb has answered it correctly IMO but I wanted to extend that answer. ASP.NET Web API which is currently in beta stage and an OSS project is the closest framework that you are looking for.
The short description of the product is as follows (quoted from ASP.NET Web API page):
ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
As for the client application that you might be using to consume your web API, it certainly doesn't have to be an ASP.NET application. You can consume your API with a static HTML page by using JavaScript. You might get this done easily with some useful JavaScript libraries such as jQuery.
On the other hand, you can certainly consume your API on the server site in any ASP.NET application. The Web API project also introduced a new HTTP .NET client API called HttpClient which makes it easy to consume HTTP services.
In general, here are good set of resources for you to get started:
Getting Started With ASP.NET Web API - Tutorials, Videos, Samples
Remember that the project is still in its beta stage. I recommend you to follow Henrik F Nielsen blog where he posts information about latest unreleased updates to project. You can reach out the source code of the project and the development flow inside ASP.NET Web Stack project.
I think the current guidence is to use MVC Web API instead of WCF for REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
The development model is pretty close and you bypass the sometimes nasty configuration of WCF.
