I have been doing some investigation regarding ASP.NET Web API. I have enjoyed using the WCF REST template to create new RESTful web services, and Web API seems to be a cleaner iteration on that.
However, I like the flexibility of WCF in allowing http, TCP, MSMQ. This aspect seems to facilitate a distributed and scalable architecture. Is it correct for me to conclude that WCF would continue to be my best bet when it comes to fire-and-forget durable message queueing?
If what you want is fire-and-forget then go with MSMQ directly, or use something like NServiceBus or MassTransit. The problem with WCF is that in attempting to abstract transport details, it ends up hiding aspects that should be explicit. The cost of abstraction is too high in my opinion.
You can use WebAPI in conjunction with MSMQ+NServiceBus. They solve very different problems. In a stereotypical architecture, you’d have a web service implemented with WebAPI which sends messages, in a fire-and-forget manner, to a messaging technology. It can also serve queries which can return processing status and results, for instance.
Whether you use WebAPI or WCF depends on your requirements. If there is a need to use TCP then go with WCF. If you can use HTTP, I’d go with WebAPI. It makes HTTP explicit and easier to work with. After all, HTTP is already a rich application protocol, why hide it?
4