I work at a small to medium enterprise that are in the business of handling the processing of transactions for the selling and purchasing of "online, electronic products". Things such as prepaid mobile airtime, mobile data, electricity and even water and gas metering.
We are a Microsoft shop and all our skills and architecture is in the Microsoft stack. We integrate to other airtime and electricity suppliers and vendors, and others integrate to us. This is done via web services with a mix of legacy .asmx web services and the newer stuff is in WCF services. We have an established data layer that talks to SQL servers and our business logic is in a huge collection of class libraries (c#).
We have a bunch of old console apps and some WinForms apps running on servers that sit and process MSMQ queues or poll SQL database tables for specific transactions to process. We are starting to rewrite these processing apps into Windows Services as this will be easier to manage via an automated deployment process such as Octopus.
Then I joined the team as the only web developer and introduced them to Microsoft's Web API framework. I've been asked if it is a good idea to use Web API as the service layer going forward instead of WCF? My gut feeling is, no, as it is more geared towards a RESTful interface which leans itself towards front-end software. Our processing apps typically go from one service call to another to the backend and so forth. Doing that via Web API is probably not going to the best fit, right?
Is it then good practice to use WCF for the processing back-end apps (Windows Services), but use Web API for the front-ends we have? We have one large WinForms app which also uses some of the WCF services and even here Web API seems a bit clunky to implement. Web API really seems more appropriate for pure web front-ends, am I on the right path here?