WCF Data Services (OData) gegen ASP.NET Web API? Hypermedia?

Ich entwerfe eine verteilte Anwendung, die aus REST-Diensten und einer Vielzahl von Clients (Silverlight, iOS, Windows Phone 7 usw.) besteht. Ich war bereit zu entscheiden, dass ich meine REST-Services mithilfe von WCF Data Services (OData) implementieren würde, aber jetzt hat mich die MVC 4-Web-API dazu veranlasst, diese Entscheidung in Frage zu stellen.

Was mir an OData gefallen hat, waren die URI-Abfrage- und Hypermedia-Funktionen, die Sie kostenlos erhalten. Was mir nicht gefiel, war die Ausführlichkeit der OData-Nutzdaten. viele unnötige Zeichen kommen über den Draht.

Was mir an der Web-API gefällt, ist, dass die Nutzdaten viel präziser sind und die URI-Abfragefunktion von OData zur Verfügung steht, es jedoch anscheinend an Hypermedia mangelt (zumindest ab Werk). Mein Chef drängt auch auf die Web-API, weil "die Kräfte, die bei Microsoft stecken, sie unterstützen und OData nicht in Schwung gekommen ist".

Ich habe also zwei Fragen:

1) Kann jemand einen Kommentar zur Unterstützung / Traktion der Web-API und der OData abgeben?

2) Wird von der Web-API erwartet, dass sie Hypermedia zum Zeitpunkt der Veröffentlichung nativ unterstützt, oder gibt es Standardimplementierungen oder -beispiele, die ich untersuchen sollte?

Vielen Dank!

Web-API macht Odata. Siehe den Blog-Beitrag von Scott Guthrie . Speziell:

Abfragezusammenstellung: Mit der Web-API können Sie das Abfragen über die OData-URL-Konventionen auf einfache Weise unterstützen. Wenn Sie eine Art von IQueryable von Ihrer Web-API zurückgeben, bietet das Framework automatisch Unterstützung für OData-Abfragen, wodurch das Implementieren von Paging und Sortieren vereinfacht wird.

Ich würde auch denken, dass in vielen Fällen die gleiche Klasse die traditionelle WCF-Klasse und die Web-API-Klasse sein könnte, sie schließen sich definitiv nicht gegenseitig aus.

Die Web-API nutzt das http-Protokoll nativer. Odata ist ein offener Standard, der von vielen Big Playern angenommen wird. Ich kann nur aus meiner Erfahrung mit Odata sprechen und habe kürzlich die Web-API entdeckt und nachgeforscht.

OData ist cool, weil es ein tatsächlicher Standard ist. Sie können problemlos eine Datenbank erstellen und über HTTP verfügbar machen. Das heißt, Sie können Ihre Tabellenstruktur ohne Konfiguration durchlaufen (ich sage das locker). Sie können Abfragen auch über die URL ausführen, die Light-LINQ enthalten kann:

/products/orders/[put some linq-ish query here]

Das ist wohl gut oder schlecht. Authentifizierung ist Standard und wurde entwickelt.

Web-API ist aus meiner Sicht interessanter. Es verwendete die HTTP-Funktionalität (Fehlermeldungen usw.) und ist für echte RESTful-Anforderungen etwas "nativer". Ich habe wirklich nicht zu viel damit gespielt. Aber ich habe herumgelesen und irgendwie "gehört", dass MVC und die Web-API eines Tages vielleicht wieder "verheiratet" sind, vielleicht gut, vielleicht schlecht ...

Als ich mit OData spielte, erstellte ich einen gespeicherten Prozess, ordnete ihn der Entity-Oberfläche zu, konfigurierte einen starken Rückgabetyp und verband ihn dann mit einer URL-Anfrage und BANG. Es gibt meine RESTful-Anfrage, die meinem gespeicherten Prozess mit eingegebenen Ergebnissen zugeordnet ist. Es war ziemlich einfach und ich konnte genau das bekommen, was ich brauchte.

Fazit: Ich hatte keine Chance, zu detailliert mit der WCF-API zu spielen, aber ich würde sagen, dass dies der richtige Weg für die Client-Entwicklung ist, da es eher eine puristische Herangehensweise an REST ist. Wenn Sie mehr oder weniger "direkt" hin und her telefonieren und "Ansichtsmodelle" abrufen, bietet dies eine native Interaktion.

Auf der anderen Seite. Wenn Sie komplexe (ish) Abfragen zu den Daten basierend auf der Clientinteraktion durchführen und die Abfragelogik "erstellen" und als Parameter übergeben möchten, funktioniert Odata möglicherweise.

So wie ich es sehe, ist es, wenn ich meine Daten in einem strukturellen Format (dh Tabellen- / Beziehungsstruktur) verfügbar machen und sie dann direkt von einem Client abfragen muss, dann funktioniert Odata am besten. Es ist auch gut, um "Anderen" den Zugriff auf die Daten zu ermöglichen (mit der richtigen Berechtigung usw.), weshalb das OData-Protokoll eingehalten wird

Wenn Sie REST-konforme Anforderungen wünschen, bei denen Sie die URL (/ products / orders / 22) diktieren und komplexe "Ergebnismengen" aus Ihrem "versteckten" verwalteten Code und Ihrer Datenstruktur erstellen, UND Sie möglicherweise auch von den HTTP-Antwortnachrichten profitieren möchten, dann die Web-API wäre wahrscheinlich die beste Wahl.

Auch dies ist alles aus Forschung und Spielerei. Ich habe weder in einem Produktions- noch in einem vollständigen App-Szenario implementiert. Ich denke, sie werden beide ihre Stärken und Schwächen haben, und es gibt definitiv einige Überschneidungen

Aus hypermedialer Sicht definitiv die Web-API. OData, das auf AtomPub basiert, ist nur eine Möglichkeit, eine Datenbank über HTTP verfügbar zu machen. Sie erhalten nur eine begrenzte Anzahl vordefinierter Statusübertragungen (CRUD). Andererseits ist ein Hypermediendienst eine auf den Kunden zugeschnittene Anwendung. Mit der Web-API können Sie alle gewünschten Links einbetten sowie die OData-Abfragesyntax verwenden. Die beste Hypermedia-Lösung im Microsoft-Stack ist ASP.NET MVC, wenn Sie HTML als Basisformat verwenden möchten.