WCF Data Services (OData) vs API Web ASP.NET


87

Sto progettando un'applicazione distribuita che consisterà in servizi RESTful e una varietà di client (Silverlight, iOS, Windows Phone 7, ecc.). In questo momento sto determinando quale tecnologia dovrei usare per implementare i miei servizi, WCF Data Services (OData) o la nuova API Web ASP.NET che uscirà con ASP.NET MVC 4.

Ho guardato alcune presentazioni online su ciascuna di esse e in questo momento mi sto orientando verso WCF Data Services principalmente a causa dei meccanismi di filtro incorporati nell'URI e nella capacità ipermedia nativa. L'unico aspetto negativo che posso vedere è la verbosità della specifica Atom Pub rispetto a POX.

C'è qualcosa che dovrei sapere su queste due tecnologie prima di prendere una decisione? Perché qualcuno dovrebbe scegliere l'API Web ASP.NET su WCF Data Services?

Risposte:


31

Questa è una domanda soggettiva, quindi ecco una risposta soggettiva. IMO, WCF ha un sovraccarico eccessivo per servizi RESTful semplici. L'API Web, d'altra parte, è stata progettata specificamente per i servizi RESTful.

Sono d'accordo con Dave Ward su questo . Controlla il suo blog per ulteriori informazioni.

Ho resistito a lungo alla pressione per passare da ASMX a WCF nei progetti WebForms, perché accettare la complessità di WCF principalmente mi ha ricompensato solo con una serializzazione JSON meno flessibile. Al contrario, ho iniziato a convertire alcuni dei miei progetti da ASMX a Web API e sono rimasto soddisfatto della facilità con cui Web API sostituisce ASMX.

Credo che Microsoft abbia finalmente trovato un buon equilibrio tra la semplicità di ASMX e la potenza di WCF con l'API Web.


2
Grazie per la risposta! Ho una domanda di follow-up, quindi spero che tu abbia abbastanza familiarità con l'API Web ASP.NET. Una cosa che mi è piaciuta di WCF Data Services sono le capacità ipermediali. Usando il loro esempio Netflix, potresti interrogare un genere di film e fuori dagli schemi il servizio restituirebbe collegamenti a ciascun film in quel genere invece dell'intera voce per ogni film. C'è un modo per farlo con l'API Web ASP.NET? Sembra che ti dia l'intera struttura degli oggetti espansa invece di utilizzare l'ipermedia.
Raymond Saltrelli

Non ho ancora avuto la possibilità di usarlo, ma sembra che tu possa implementarlo MediaTypeFormatterper formattare le tue risposte. Vedi code.msdn.microsoft.com/Contact-Manager-Web-API-0e8e373d per un esempio.
jrummell

2
È una specie di dolore. Speravo che ci sarebbe stato un qualche tipo di configurazione per attivarlo. E se accadesse automagicamente. Il mio capo sta spingendo per l'API Web perché tutti i poteri di MS lo sostengono. Sembra tutto andrà bene. Il suo payload è più conciso di OData, ha le capacità di interrogazione URI di OData, manca solo l'hypermedia out-of-the-box. Forse troverà la sua strada entro il momento del rilascio.
Raymond Saltrelli

1
Penso che questa risposta dovrebbe essere riesaminata poiché Microsoft sta sottolineando di utilizzare OData Web API su Web Api.
codebased

111

Attualmente ci sono altre grandi differenze tra WebApi e WCF Data Services, che nessuno sembra mai menzionare. Vorrei che MS uscisse con un buon articolo che confronta i due.

Seguo OData da un po 'e anche WebApi. Ho sempre trovato alcune importanti distinzioni.

Innanzitutto, non sono sicuro di cosa intenda il tuo capo con "MS sta supportando WebApi", nel senso che non stanno supportando OData ?? IMO, stanno sostenendo entrambi e attualmente c'è una minima sovrapposizione. Windows Azure Data Market espone i propri dati utilizzando OData, Azure Table Storage utilizza OData, SharePoint 2010 consente query OData sui suoi dati e anche altri prodotti di MS lo supportano, come Excel PowerPivot. È un framework di query molto potente quando si tratta di dati relazionali. E poiché è RESTful, qualsiasi linguaggio, framework, dispositivo, ecc. Può integrarsi con esso.

Ecco cosa mi piace di OData + WCF Data Services:

OData + WCF Data Services ha finalmente consentito alle applicazioni client di essere più "espressive" durante le query sui dati sul Web. Prima, dovevamo sempre utilizzare ASMX o WCF per creare API Web rigide che diventano poco maneggevoli e richiedono modifiche costanti ogni volta che un'interfaccia utente desidera qualcosa di leggermente diverso. L'applicazione client poteva solo specificare parametri per stabilire quali criteri restituire. Oppure fai come ho fatto io e "Serializza" le espressioni LINQ e passale come parametri e reidratati Expressions<Func<T,bool>>sul server. È decente. Ho completato il lavoro, ma desidero utilizzare LINQ sul client e tradurlo sul Web utilizzando REST, che è esattamente ciò che consente OData e non voglio utilizzare il mio "hack" di una soluzione.

È come esporre "TRANSACT SQL" senza la necessità di una stringa di connessione DB. Fornisci semplicemente un URL e whoala! Inizia a interrogare. Naturalmente, sia WebApi che WCF Data Services supportano l'autenticazione / autorizzazione, quindi puoi controllare l'accesso, aggiungere ulteriori istruzioni "Where" in base ai ruoli o ad altre configurazioni dei dati. Preferisco farlo nel mio Web Api Layer che in SQL (come la creazione di viste o Processi archiviati). E ora che le applicazioni possono creare da sole le query, vedrai che gli strumenti di reportistica ad hoc e BI iniziano a sfruttare OData e consentono agli utenti di definire i propri risultati. Non fare affidamento sui rapporti statici in cui hanno un controllo minimo.

Quando si sviluppa in Silverlight, Windows 8 Metro o ASP.NET (MVC, WebForms, ecc.), È possibile aggiungere semplicemente un "Riferimento al servizio" in Visual Studio al WCF Data Service e iniziare rapidamente a utilizzare LINQ per eseguire query sui dati E si ottiene un "Data Context" sul client, il che significa che tiene traccia delle modifiche e consente di "inviare" le modifiche in modo atomico al server. Questo è molto simile a RIA Services per Silverlight. Avrei usato WCF Data Services invece di RIA Services, ma all'epoca non supportava DataAnnotations o Actions, ma ora lo fa :) WCF Data Services ha un altro vantaggio rispetto a RIA Services, ovvero la capacità di eseguire "proiezioni" dal Cliente. Questo può aiutare con le prestazioni, nel caso in cui non voglio restituire tutte le proprietà da un'entità. Avere un "contesto dei dati"

Pertanto, WCF Data Services è ottimo se si dispone di dati con relazioni, soprattutto se si utilizzano SQL Server ed Entity Framework. Sarai rapidamente in grado di esporre dati interrogabili + azioni (chiamate per richiamare operazioni, ad esempio flussi di lavoro, processi in background) su REST con pochissimo codice. WCF Data Services è stato appena aggiornato. Lanciata una nuova versione. Scopri tutte le nuove funzionalità.

Lo svantaggio di WCF Data Services è il "controllo" che si perde sullo Stack HTTP. Ho scoperto che il difetto più grande era nei IQueryable<T>metodi che restituiscono le raccolte. A differenza dei servizi RIA E WebApi, NON hai pieno accesso per sviluppare la logica nel metodo IQueryable. In RIA Services e WebApi, puoi scrivere qualsiasi codice desideri finché ritorni IQueryable<T>. In WCF Data Services, puoi SOLO accedere per aggiungere un'istruzione "Where" utilizzandoExpression<Func<T,bool>> metodi di intercettazione. L'ho trovato deludente. La nostra attuale applicazione utilizza i servizi RIA e trovo che abbiamo davvero bisogno della capacità di controllare la logica IQueryable. Spero di sbagliarmi su questo e mi manca qualcosa

Inoltre, WCF Data Services NON supporta ancora completamente tutti gli operatori LINQ. Tuttavia, supporta ancora più di WebApi.

Che mi dici di WebApi ???

  1. Mi piace il controllo su Http Request / Response
  2. È facile da seguire (sfruttando i modelli MVC). Sono sicuro che arriveranno altri strumenti.

A partire da ora (per quanto ne so), non esiste alcun supporto "Data Context" sul client (ad esempio Silverlight, ASP.NET Server-Side Code, ecc.), Perché WebApi non riguarda realmente i modelli di dati di entità come WCF Data Services / OData è. Può esporre collezioni di oggetti modello utilizzando IQueryable / IEnumerable, ma non ci sono "Proprietà di navigazione" chiave primaria / chiave esterna (es. Cliente.Invoices) da utilizzare una volta caricate le entità sul client, perché non esiste un "contesto dati" che li carica in modo asincrono (o in una chiamata utilizzando $ expand) e gestisce le modifiche. Non hai una "rappresentazione" generata dal codice del tuo Entity Data Model sul client, come fai in RIA Services o WCF Data Services. Non sto dicendo che non puoi / non hai Modelli nel Cliente che rappresentano i tuoi Dati, ma devi compilare manualmente i Dati e gestire quali "fatture" devono essere impostate con ciascun "cliente" una volta recuperate sul Web. Questo può diventare complicato, specialmente con tutte le cose Async in corso. Non sai quali chiamate verranno richiamate per prime. Questo può essere difficile da spiegare qui, ma leggi solo le informazioni sul "contesto dei dati" in RIA Services oServizi dati WCF . Quindi, quando si tratta di app Line of Business, questo è un problema importante per me. Ciò si basa principalmente sulla produttività e sulla manutenibilità. Puoi creare obsolete app senza un contesto dati. Semplifica semplicemente le cose, specialmente in Silverlight, WPF e ora in Windows 8 Metro. Avere entità relazionali caricate in memoria in modo asincrono e avere Two-Binding è davvero bello da avere.

Detto questo, questo significa che un giorno WebApi potrà supportare un "Data Context" sul client? Penso che potrebbe. Inoltre, con più strumenti, un progetto Visual Studio potrebbe generare tutti i metodi CRUD basati su uno schema di database (o Entity Framework).

Inoltre, so di menzionare solo .NET in .NET Frameworks quando si tratta di lavorare con WCF Data Services o WebApi, ma sono ben consapevole che HTML / JS è anche un attore importante. Stavo solo menzionando i vantaggi che ho riscontrato quando ho a che fare con un'interfaccia utente Silverlight, o un codice lato server ASP.NET, ecc. Credo che con l'avvento di "IndexedDB" in HTML5 / JavaScript che avere un "Contesto dati" e un Potrebbe anche diventare disponibile il framework LINQ in JavaScript, rendendo la capacità di eseguire query sui servizi OData ancora più semplice da JavaScript (oggi è possibile utilizzare DataJS con OData). Inoltre, l'utilizzo di KnockoutJS per supportare MVVM e Binding in HTML / JS lo renderà un gioco da ragazzi :)

Attualmente sto cercando quale piattaforma utilizzare. Sarei felice di utilizzare entrambi, ma tendo a propendere per OData in base al fatto che la mia prossima applicazione riguarda principalmente Analytics (sola lettura) e voglio una ricca API RESTful espressiva. Credo che OData + WCF Data Services me lo dia perché WebApi supporta solo $ take, $ skip, $ filter, $ orderby su Collections. NON supporta proiezioni, include ($ expand), ecc. Non ho molti "aggiornamenti / eliminazioni / inserimenti" ei nostri dati sono abbastanza relazionali.

Spero che altri si uniranno alla discussione e daranno i loro pensieri. Sto ancora decidendo e mi piacerebbe sentire altre opinioni. Penso davvero che entrambi i framework siano fantastici. Mi chiedo se devi anche solo scegliere, perché non usarli entrambi se necessario. Dal client si tratta comunque di creare chiamate REST. Solo un pensiero :)


4
Web Api ha una nuova anteprima per il supporto OData che aggiunge peacies mancanti e lo pone sulle stesse basi utilizzate da WCF DS: [link] [ blogs.msdn.com/b/alexj/archive/2012/08/15/…
Johannes Rudolph

@JohannesRudolph - Il link che hai fornito sembra interessante ma è rotto.
Olly

OK, penso sia solo un problema di formattazione. Dovrebbe essere: blogs.msdn.com/b/alexj/archive/2012/08/15/… .
Olly

Anche Web Api ha bisogno di questo piccolo amore per lavorare su versioni di Excel precedenti al 2013: aspnetwebstack.codeplex.com/workitem/820
David d C e Freitas

5
Dato che siamo nel 2014 ora, Microsoft ha un interessante post sul blog blogs.msdn.com/b/odatateam/archive/2014/03/27/… per discutere il futuro del supporto OData da WCF e WebApi.
hardywang

26

Riteniamo che l'API Web fornisca la piattaforma giusta per i servizi OData in futuro e come tale investirà principalmente in quella piattaforma per stack di server OData. Ovviamente continueremo a mettere risorse significative nelle librerie e nel client di base OData, ma prevediamo di ridurre gli investimenti in WCF Data Services come stack per la creazione di servizi OData.

Blog del team di OData

Quindi, sembra che ora sia tutto abbastanza chiaro


16

Sia l'API Web che WCF Data Services supportano OData immediatamente. Con WCF Data Services (WCFDS), è automatico. Con l'API Web, torna IQueryabledal controller e contrassegna il metodo con [Queryable]. Questo ti darà la $filterfunzionalità di cui stavi parlando. E se lo fai in questo modo, entrambi possono gestire automaticamente JSON nella risposta inserendo accept=application/jsonl'intestazione della richiesta. OData di WCFDS supporta alcune parole chiave OData in più rispetto all'API Web (sebbene $expandvenga in mente solo la parola chiave), ma sono sicuro che il tempo risolverà questo problema.

Sia i client .NET che le pagine HTML possono richiamare facilmente entrambe queste alternative, ma se ti piace LINQ e stai creando client .NET, WCFDS può essere aggiunto al tuo progetto come riferimento del servizio. Ciò ti consente di saltare tutte le attività HTTP e interrogare direttamente le raccolte.

La conclusione è che nulla ti impedisce di inserire file .svc nel tuo progetto ASP.Net MVC. Non è una proposta o una o l'altra. L'aggiunta di servizi dati al tuo server ti farà risparmiare la necessità di scrivere molti controller, ma non ti impedisce di scrivere controller aggiuntivi se lo desideri.


6

In altre parole :

Se stai cercando di esporre rapidamente un modello di dati (EDM o altro) e non hai bisogno di molto codice o logica di business, WCF Data Services lo rende DAVVERO facile e sarebbe un buon punto di partenza.

Se si sta creando un'API e si desidera semplicemente esporre alcune risorse (e logica) utilizzando la sintassi o la formattazione della query OData, l' API Web ASP.NET è probabilmente il punto di partenza migliore.

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx


5

Devaron ha fornito la recensione più istruttiva di WCF vs Web Api che devo ancora trovare. Grazie. Ora, al punto che WCF è troppo complesso, dirò che la complessità non è automaticamente negativa. Sarai grato per il respiro che ti offre in futuro. La sfida, come sempre con gli strumenti Microsoft, è che non conosciamo o controlliamo quel futuro. Speriamo che Microsoft finisca con un sistema più unificato e che rimanga in circolazione per alcuni anni.

Ho anche un grande sistema da costruire e mi sottolinea che il percorso non è più chiaro. Ho intenzione di resistere per un altro paio di mesi mentre tutto si risolve. E personalmente sto facendo il tifo per datajs (controlla anche JayData)


1

Mettilo in questo modo in termini più semplici, fai un passo indietro dal protocollo sottostante e guarda questo dal punto di vista dello sviluppatore / utente. L'API Web è il Rest Framework di prima classe basato su HTTP di Microsoft, non WCF. Ciò significa che eventuali funzionalità e specifiche Rest mancanti verranno aggiunte alla pipe API Web e non necessariamente a WCF.

Sì, puoi implementarli tu stesso in WCF ma come dice nella frase devi implementarli tu stesso.

Proprio come un esempio oggi, l'implementazione di un'autenticazione a 2 fattori per un'API Web richiede meno di 15 minuti utilizzando OWIN che è principalmente un pacchetto nuget di autenticazione / autorizzazione che è iniziato come progetto open source.

Quando si utilizza uno stack tecnologico, è fondamentale utilizzare lo stack di prima classe per Microsoft. Avresti anche innumerevoli codici e progetti di esempio pubblicati da MS in GitHub che puoi semplicemente copiare e dare un vantaggio al tuo progetto. Fa la differenza a ogni livello, documentazione, esempi di codice, set di funzionalità, supporto, API di supporto come lo chiami.

Quindi il mio semplice consiglio per te, se vuoi creare applicazioni basate su HTTP Restfull usa l'API web (o ASP.NET Core per la portabilità) e stai davvero lontano da WCF. Se il protocollo non è HTTP e in realtà non può essere HTTP, utilizzare WCF.


0

Questa è la risposta TL; DR a questa domanda.

WCF è il coltellino svizzero per il cacciavite dell'API WEB per la comunicazione e il trasferimento dei dati: WCF può fare tutto ciò che può fare l'API WEB, ma, se hai bisogno di più (ad esempio, utilizzando il protocollo TCP), WCF è la strada da percorrere.

Ecco un ottimo confronto .

API WEB

Il motivo numero uno per utilizzare l'API WEB è che è leggero. Ciò significa che è più semplice da implementare, più facile da imparare, più facile da mantenere, ecc. È progettato specificamente per il Web, che necessita di servizi Web RESTful su HTTP. Lo fa e lo fa bene. Se questo è tutto ciò di cui hai bisogno, l'API WEB è probabilmente la strada da percorrere.

Inoltre, è Open Source (se ti interessa)

WCF

WCF fa molto di più dell'API WEB: supporta più protocolli di trasferimento, più modelli di scambio (l'API WEB richiede l'integrazione con SignalR o Web Sockets), i servizi SOAP possono essere descritti in WSDL, ha funzionalità di sicurezza aggiuntive e altro ancora. Vai con WCF se hai bisogno di questa funzionalità aggiuntiva.

OData

OData è semplicemente

Un protocollo aperto per consentire la creazione e l'utilizzo di API RESTful interrogabili e interoperabili in modo semplice e standard. fonte: http://www.odata.org/

In altre parole, di alto livello, sta solo standardizzando una grammatica specifica per le richieste HTTP RESTful. Che fornirà gli stessi vantaggi di qualsiasi protocollo. E almeno dal 2013 sia WCF che WEB API consentono l'uso di OData. Quindi, probabilmente non vale la pena preoccuparsi di OData.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.