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?

| improve this answer | |
  • 1
    it ends up hiding aspects that should be explicit - what are you referring to here, HTTP-specific aspects? – Kirk Broadhurst Nov 28 '12 at 1:31
  • Yes, HTTP specifics, or MSMQ specifics for that matter. – eulerfx Nov 28 '12 at 1:39
  • why would you use MSMQ and NServiceBus? – dave thieben Dec 3 '12 at 14:50
  • MSMQ is the default transport used by NServiceBus. – eulerfx Dec 3 '12 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.