Lavoro in una piccola e media impresa che gestisce l'elaborazione di transazioni per la vendita e l'acquisto di "prodotti elettronici online". Cose come il tempo di trasmissione mobile prepagato, dati mobili, elettricità e persino la misurazione di acqua e gas.
Siamo un negozio Microsoft e tutte le nostre competenze e architettura sono nello stack Microsoft. Ci integriamo con fornitori e distributori di airtime ed elettricità, e altri ci integrano. Ciò avviene tramite servizi Web con un mix di servizi Web .asmx legacy e le novità riguardano i servizi WCF. Abbiamo un livello dati stabilito che parla con i server SQL e la nostra logica aziendale si trova in un'enorme raccolta di librerie di classi (c #).
Abbiamo una serie di vecchie app per console e alcune app di WinForm in esecuzione su server che ospitano ed elaborano code MSMQ o eseguono il polling di tabelle di database SQL per transazioni specifiche da elaborare. Stiamo iniziando a riscrivere queste app di elaborazione in Servizi Windows in quanto ciò sarà più facile da gestire tramite un processo di distribuzione automatizzato come Octopus.
Poi sono entrato nel team come unico sviluppatore web e li ho introdotti al framework API Web di Microsoft. Mi è stato chiesto se è una buona idea utilizzare l'API Web mentre il livello di servizio va avanti invece di WCF? Il mio istinto è, no, in quanto è più orientato verso un'interfaccia RESTful che si appoggia al software di front-end. Le nostre app di elaborazione passano in genere da una chiamata di servizio a un'altra al backend e così via. Fare ciò tramite l'API Web probabilmente non si adatta al meglio, giusto?
È quindi buona norma utilizzare WCF per le applicazioni di back-end di elaborazione (Servizi Windows), ma utilizzare le API Web per i front-end che abbiamo? Abbiamo una grande app WinForms che utilizza anche alcuni dei servizi WCF e anche qui l'API Web sembra un po 'goffa da implementare. Le API Web sembrano davvero più appropriate per i front-end puri del Web, sono sulla strada giusta qui?