Ho trascorso alcuni mesi cercando di cogliere i concetti alla base di WCF e recentemente ho sviluppato la mia prima applicazione di servizio WCF.

Ho faticato parecchio a capire tutte le impostazioni nel file di configurazione.
Non sono convinto dell'ambiente ma sembra che tu possa fare cose fantastiche con esso.

L'altro giorno ho scoperto che Microsoft è uscita con una nuova cosa chiamata API Web ASP.NET .

Per quello che posso leggere è un framework RESTful , molto facile da usare e da implementare.

Ora sto cercando di capire quali sono le principali differenze tra i 2 framework e se dovessi provare a convertire la mia vecchia applicazione di servizio WCF con la nuova API.

Qualcuno potrebbe aiutarmi a capire le differenze e l'uso di ciascuno?

La nuova API Web ASP.NET è una continuazione del precedente progetto API Web WCF (anche se alcuni concetti sono cambiati ).

WCF è stato originariamente creato per abilitare i servizi basati su SOAP. Per servizi RESTful o RPCish più semplici (si pensi a client come jQuery), l'API Web ASP.NET dovrebbe essere una buona scelta.

Per noi, WCF è utilizzato per SOAP e API Web per REST. Vorrei che anche l'API Web supportasse SOAP. Non stiamo utilizzando le funzionalità avanzate di WCF. Ecco un confronto da MSDN :

L'API Web ASP.net è interamente basata su HTTP e REST GET, POST, PUT, DELETE con ben noto stile di programmazione ASP.net MVC e JSON restituibile; API Web è per tutto il processo leggero e componenti puramente basati su HTTP. Uno per andare avanti con WCF anche per un servizio web singolo semplice o più semplice porterà tutto il bagaglio extra. Per un servizio semplice e leggero per ajax o chiamate dinamiche, WebApi risolve sempre la necessità. Questo integra perfettamente o aiuta in parallelo al MVC ASP.net.

Dai un'occhiata al podcast: Hanselminutes Podcast 264 - Questa non è la WCF di tuo padre - Tutto sulla WebAPI con Glenn Block di Scott Hanselman per ulteriori informazioni.

Negli scenari elencati di seguito dovresti scegliere WCF:

1. Se è necessario inviare dati su protocolli come TCP, MSMQ o MIME
2. Se il client che consuma sa come consumare i messaggi SOAP

L'API WEB è un framework per lo sviluppo di servizi RESTful / HTTP.

Esistono così tanti client che non comprendono SOAP come Browser, HTML5, in quei casi le API WEB sono una buona scelta.

L'intestazione dei servizi HTTP specifica come proteggere il servizio, come memorizzare nella cache le informazioni, il tipo di corpo del messaggio e il corpo HTTP può specificare qualsiasi tipo di contenuto come HTML non solo XML come servizi SOAP.

Da quando ho usato entrambi fino ad ora, ho trovato molte differenze tra WCF e API Web. Entrambi gli stack tecnologici si adattano bene a diversi scenari, quindi non è possibile dire quale sia la migliore, questo dipende dalla configurazione e dallo scenario.

Properties              ASP.Net Web API                         WCF
--------------------------------------------------------------------------------------------------
End point (mainly)      Http based                              SOAP based
Service Type            Front End                               Back-end
Support                 caching, compression, versioning        No
Framework               ASP.net                                 WCF
Orientation             Resource Oriented                       Service Oriented
Transports              http                                    http, tcp, MSMQ, Named pipe
Message pattern         Request reply                           request Reply, one way, duplex
Configuration overhead  Less                                    Much
Security                lesser than WCF (web standard security) Very high (WS-I standard)
Hosting                 IIS                                     IIS, Windows Service, Self hosting
Performance             Fast                                    A bit slower than Web API
In use from             .NET 4.0                                .NET 3.5

Nota: i dati non sono solo a mio avviso, ma sono anche raccolti da altri siti Web ufficiali.

WCF ti darà così tanto fuori dagli schemi, non è nemmeno paragonabile a niente. A meno che non si desideri eseguire la propria implementazione di (solo per citarne alcuni) autenticazione, autorizzazione, crittografia, accodamento, limitazione, messaggistica affidabile, registrazione, sessioni e così via. WCF non è [solo] servizi web; WCF è una piattaforma di sviluppo per SOA.

Perché sto rispondendo:

Ho impiegato molto tempo per capire la differenza tra queste due tecnologie. Metterò qui tutti quei punti che penso "Se avessi questi punti nel momento in cui mi chiedevo in giro alla ricerca di questa risposta, allora ho deciso molto prima di selezionare la mia tecnologia richiesta".

Fonte d'informazione:

Microsoft® Visual Studio® 2015 scatenato

ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3

Perché ASP.NET Web API e WCF:

Prima di confrontare le tecnologie di ASP.NET Web API e WCF, è importante capire che in realtà esistono due stili / standard per la creazione di servizi Web: REST (Representational State Transfer) e SOAP / WSDL. SOAP / WSDL era lo standard originale su cui erano costruiti i servizi web. Tuttavia, era difficile da usare e aveva formati di messaggi ingombranti (come XML) che degradavano le prestazioni. I servizi basati su REST sono diventati rapidamente l'alternativa. Sono più facili da scrivere perché sfruttano i costrutti di base di HTTP (GET, POST, PUT, DELETE) e in genere utilizzano formati di messaggi più piccoli (come JSON). Di conseguenza, i servizi HTTP basati su REST sono ora lo standard per i servizi di scrittura destinati esclusivamente al Web.

Definiamo lo scopo dell'API Web ASP.NET

L'API Web ASP.NET è la tecnologia di Microsoft per lo sviluppo di servizi Web HTTP basati su REST. (Molto tempo fa ha sostituito ASMX di Microsoft, che era basato su SOAP / WSDL.) L'API Web semplifica la scrittura di servizi affidabili basati su protocolli HTTP che tutti i browser e dispositivi nativi comprendono. Ciò consente di creare servizi per supportare l'applicazione e chiamarli da altre applicazioni Web, tablet, telefoni cellulari, PC e console di gioco. La maggior parte delle applicazioni scritte oggi per sfruttare la sempre presente connessione Web utilizza i servizi HTTP in qualche modo.

Definiamo ora lo scopo di WCF:

Comunicare attraverso Internet non è sempre il mezzo più efficiente. Ad esempio, se sia il client che il servizio esistono sulla stessa tecnologia (o anche sulla stessa macchina), possono spesso negoziare un mezzo più efficiente per comunicare (come TCP / IP). Gli sviluppatori di servizi si sono trovati a fare le stesse scelte che stavano cercando di evitare. Ora dovrebbero scegliere tra la creazione di servizi interni efficienti e la possibilità di avere un ampio accesso trovato su Internet. E, se dovessero supportare entrambi, potrebbero dover creare più versioni del loro servizio o almeno proxy separati per accedere al loro servizio. Questo è il problema che Microsoft ha risolto con WCF .

Con WCF, puoi creare il tuo servizio senza preoccuparti dei confini. È quindi possibile lasciare che WCF si preoccupi dell'esecuzione del servizio nel modo più efficiente, a seconda del client chiamante. Per gestire questa attività, WCF utilizza il concetto di endpoint. Il servizio potrebbe avere più endpoint (configurato in fase di progettazione o dopo la distribuzione). Ogni endpoint indica come il servizio potrebbe supportare un client chiamante: sul Web, tramite remoto, tramite Accodamento messaggi Microsoft (MSMQ) e altro. WCF ti consente di concentrarti sulla creazione della tua funzionalità di servizio. Si preoccupa di come parlare in modo più efficiente con i clienti chiamanti. In questo modo, un singolo servizio WCF può supportare in modo efficiente molti tipi di client diversi.

Esempio di WCF:

Considera l'esempio:

I dati del cliente vengono condivisi tra le applicazioni. Ogni applicazione potrebbe essere scritta su una piattaforma diversa e potrebbe esistere in una posizione diversa. È possibile estrarre l'interfaccia del cliente in un servizio WCF che fornisce un accesso comune ai dati condivisi del cliente. Ciò centralizza i dati, riduce la duplicazione, elimina la sincronizzazione e semplifica la gestione. Inoltre, utilizzando WCF, è possibile configurare gli endpoint del servizio affinché funzionino in modo sensato per il client chiamante. La figura mostra l'esempio precedente con accesso centralizzato ai dati dei clienti in un servizio WCF.

Conclusione:

i) Quando scegliere l'API Web:

Non si può negare che i servizi HTTP basati su REST come quelli creati utilizzando l'API Web ASP.NET siano diventati lo standard per la creazione di servizi Web. Questi servizi offrono un approccio semplice e diretto per gli sviluppatori di servizi Web che creano servizi. Gli sviluppatori Web comprendono HTTP GET e POST e quindi si adattano bene a questi tipi di servizi. Pertanto, se stai scrivendo servizi strettamente mirati a HTTP , l'API Web ASP.NET è la scelta logica.

ii) Quando scegliere WCF:

La tecnologia WCF è utile quando è necessario supportare più endpoint di servizio basati su protocolli e formati di messaggio diversi. Prodotti come Microsoft BizTalk sfruttano WCF per la creazione di servizi affidabili che possono essere utilizzati anche sul Web tramite diverse configurazioni machine-to-machine. Tuttavia, è necessario scrivere un'applicazione che comunica su TCP / IP quando si è connessi al locale rete e funziona su HTTP quando fuori dalla rete, WCF è la tua risposta .

Attenzione:

Gli sviluppatori Web spesso vedono WCF come più difficili e complessi da sviluppare. Pertanto, se non si prevede la necessità di servizi multiprotocollo, è probabile che si verifichi l'API Web ASP.NET.

C'è un confronto su MSDN su questo

API Web WCF e ASP.NET

Per me, la scelta era su Chi sono i clienti e dove si trovano?

All'interno della rete aziendale e client basati su .NET: utilizzare WCF con associazione TCP (comunicazione rapida rispetto a HTTP)

Al di fuori della rete aziendale e utilizzare diverse tecnologie come PHP, Python ecc .: Utilizzare l'API Web con REST

Parlando di affari, WebApi manca di un WSDL, quindi gli sviluppatori dovrebbero documentare tutto manualmente. E se, ad esempio, l'operazione WebApi restituisce un elenco di oggetti, il client deve creare gli oggetti manualmente, ovvero WebAPI è realmente soggetto a errori di definizione.

Il pro di Webapi è più leggero di WCF.

Per quanto riguarda l'affermazione "Mancanze WebApi di WSDL", esistono diversi modi per generare il client Rest. Un approccio popolare è Swagger UI / (Swashbukkle Nuget). Ciò fornisce una ricca interfaccia per comprendere lo schema di input e output dell'end point REST e lo strumento online per testare gli endpoint.

JSON LD (Json Linked Documents) è un altro standard emergente che migliorerà ulteriormente l'esperienza di sviluppo REST basata su JSON esponendo lo schema JSON con una migliore semantica.

Con wcf siamo in grado di configurare ed esporre lo stesso supporto di servizio per più endpoint come tcp, http.se si desidera che il proprio servizio sia basato solo su HTTP, quindi sarà meglio utilizzare l'API Web. L'API Web ha una configurazione molto inferiore rispetto a wcf ed è leggermente più veloce di wcf. Wcf supporta anche servizi riposanti. Se hai una limitazione di .Net framework 3.5, l'opzione è wcf.