Usługi danych WCF (OData) kontra interfejs API sieci Web ASP.NET

Projektuję rozproszoną aplikację, która będzie składać się z usług RESTful i różnych klientów (Silverlight, iOS, Windows Phone 7 itp.). W tej chwili określam, której technologii należy użyć do wdrożenia moich usług, usług danych WCF (OData) lub nowego interfejsu API sieci Web ASP.NET, który wychodzi z ASP.NET MVC 4.

Obejrzałem kilka prezentacji online na temat każdego z nich i teraz skłaniam się ku usługom danych WCF głównie ze względu na mechanizmy filtrowania wbudowane w funkcję URI i natywne hipermedia. Jedynym minusem, jaki widzę, jest szczegółowość specyfikacji Atom Pub w przeciwieństwie do POX.

Czy jest coś, co powinienem wiedzieć o tych dwóch technologiach przed podjęciem decyzji? Dlaczego ktoś miałby wybrać interfejs API sieci Web ASP.NET zamiast usług danych WCF?

To jest subiektywne pytanie, więc oto subiektywna odpowiedź. IMO, WCF ma o wiele za dużo narzutów dla prostych usług RESTful. Z drugiej strony interfejs API sieci Web został zaprojektowany specjalnie dla usług RESTful.

Zgadzam się w tej sprawie z Dave'em Wardem . Sprawdź jego blog, aby uzyskać więcej informacji.

Od dawna opierałem się presji przejścia z ASMX na WCF w projektach WebForms, ponieważ zaakceptowanie złożoności WCF przede wszystkim nagrodziło mnie mniej elastyczną serializacją JSON. Z kolei zacząłem konwertować niektóre z moich projektów z ASMX na Web API i byłem zadowolony z tego, jak łatwo Web API zastępuje ASMX.

Uważam, że Microsoft wreszcie znalazł dobrą równowagę między prostotą ASMX a mocą WCF dzięki Web API.

Obecnie istnieją inne główne różnice między usługami WebApi i WCF Data Services, o których nikt nigdy nie wspomina. Chciałbym, żeby stwardnienie rozsiane wyszło z dobrym artykułem porównującym te dwa.

Od jakiegoś czasu śledzę OData, a także WebApi. Zawsze znajdowałem kilka głównych wyróżnień.

Po pierwsze, nie jestem pewien, co twój szef ma na myśli mówiąc „MS wspiera WebApi”, co oznacza, że ​​nie wspierają OData? IMO, popierają oba te rozwiązania i obecnie w minimalnym stopniu się pokrywają. Windows Azure Data Market udostępnia swoje dane za pomocą OData, Azure Table Storage korzysta z OData, SharePoint 2010 zezwala na zapytania OData na swoich danych, a inne produkty firmy MS również je obsługują, takie jak Excel PowerPivot. Jest to bardzo potężny framework zapytań, jeśli chodzi o dane relacyjne. A ponieważ jest to RESTful, można z nim zintegrować dowolny język, framework, urządzenie itp.

Oto, co lubię w usługach danych OData + WCF:

Usługi danych OData + WCF wreszcie umożliwiły aplikacjom klienckim bardziej „ekspresyjne” wykonywanie zapytań dotyczących danych w sieci Web. Wcześniej zawsze musieliśmy używać ASMX lub WCF do tworzenia sztywnych interfejsów API sieci Web, które stają się nieporęczne i wymagają ciągłych zmian, gdy interfejs użytkownika chce czegoś nieco innego. Aplikacja kliencka mogła jedynie określać parametry decydujące o tym, jakie kryteria mają zostać zwrócone. Albo zrób tak, jak ja i „Serializuj” wyrażenia LINQ i przekaż je jako parametry i ponownie nawadniaj Expressions<Func<T,bool>>na serwerze. Jest przyzwoity. Wykonałem zadanie, ale chcę użyć LINQ na kliencie i przetłumaczyć go przez sieć WWW przy użyciu REST, co jest dokładnie tym, na co pozwala OData i nie chcę używać własnego „hackowania” rozwiązania.

To tak, jakby udostępniać „TRANSACT SQL” bez konieczności podawania parametrów połączenia z bazą danych. Po prostu podaj adres URL i whoala! Rozpocznij zapytanie. Oczywiście zarówno usługi WebApi, jak i usługi danych WCF obsługują uwierzytelnianie / autoryzację, dzięki czemu można kontrolować dostęp, dołączać dodatkowe instrukcje „Where” na podstawie ról lub innej konfiguracji danych. Wolałbym to zrobić w mojej warstwie Web Api niż w SQL (jak budowanie widoków lub przechowywanych procesów). A teraz, gdy aplikacje mogą same tworzyć zapytania, zobaczysz, że narzędzia Ad-Hoc i BI Reporting zaczynają wykorzystywać OData i pozwalają Użytkownikom definiować własne wyniki. Nie poleganie na raportach statycznych, gdzie mają minimalną kontrolę.

Podczas programowania w Silverlight, Windows 8 Metro lub ASP.NET (MVC, WebForms itp.) Możesz po prostu dodać „Service Reference” w programie Visual Studio do usługi danych WCF i szybko rozpocząć korzystanie z LINQ do wykonywania zapytań dotyczących danych ORAZ otrzymasz „Kontekst danych” na kliencie, co oznacza, że ​​śledzi zmiany i umożliwia „przesłanie” zmian atomowo z powrotem na serwer. To bardzo podobne do usług RIA dla Silverlight. Korzystałbym z usług danych WCF zamiast usług RIA, ale w tamtym czasie nie obsługiwały one adnotacji danych ani akcji, ale teraz tak. od klienta. Może to pomóc w zwiększeniu wydajności, na wypadek, gdyby nie chcę zwracać wszystkich właściwości z jednostki. Posiadanie „kontekstu danych”

Tak więc usługi danych WCF są świetne, jeśli masz dane z relacjami, zwłaszcza jeśli używasz programu SQL Server i Entity Framework. Szybko będziesz w stanie udostępnić Queryable Data + Actions (wywołania do wywołania operacji, tj. Przepływy pracy, procesy w tle) przez REST z bardzo małą ilością kodu. Usługi danych WCF zostały właśnie zaktualizowane. Uruchomiono nową wersję. Sprawdź wszystkie nowe funkcje.

Wadą usług danych WCF jest „kontrola” tracona w stosie HTTP. Największą wadę znalazłem w IQueryable<T>metodach zwracających kolekcje. W przeciwieństwie do usług RIA i WebApi NIE masz pełnego dostępu do tworzenia logiki w metodzie IQueryable. W usługach RIA i WebApi możesz pisać dowolny kod, o ile wrócisz IQueryable<T>. W usługach danych programu WCF można uzyskać dostęp TYLKO do dołączania instrukcji „Where” przy użyciu Expression<Func<T,bool>>metod przechwytujących. To mnie rozczarowało. Nasza obecna aplikacja korzysta z usług RIA i uważam, że naprawdę potrzebujemy możliwości kontrolowania logiki IQueryable. Mam nadzieję, że się mylę i po prostu czegoś mi brakuje

Ponadto usługi danych WCF nie obsługują jeszcze w pełni wszystkich operatorów LINQ. Jednak nadal obsługuje więcej niż WebApi.

A co z WebApi ???

1. Podoba mi się kontrola nad żądaniem / odpowiedzią HTTP
2. Jest łatwy do naśladowania (wykorzystując wzorce MVC). Jestem pewien, że pojawi się więcej narzędzi.

W chwili obecnej (w moim rozumieniu) nie ma obsługi „kontekstu danych” na kliencie (tj. Silverlight, kod po stronie serwera ASP.NET itp.), Ponieważ WebApi tak naprawdę nie dotyczy modeli danych encji, takich jak usługi danych WCF / OData jest. Może ujawniać kolekcje obiektów modelu przy użyciu IQueryable / IEnumerable, ale nie ma „właściwości nawigacji” klucza podstawowego / klucza obcego (tj. Faktur klienta) do użycia po załadowaniu jednostek do klienta, ponieważ nie ma „kontekstu danych” który ładuje je asynchronicznie (lub w jednym wywołaniu za pomocą $ expand) i zarządza zmianami. Nie masz wygenerowanej przez kod „reprezentacji” Entity Data Model na kliencie, tak jak w przypadku usług RIA lub usług danych WCF. Nie mówię, że nie możesz / nie masz modeli w kliencie, które reprezentują Twoje dane, ale musisz ręcznie wypełnić dane i zarządzać tym, które „faktury” mają być ustawione dla każdego „klienta” po ich pobraniu przez Internet. Może to być trudne, szczególnie w przypadku wszystkich rzeczy związanych z Async. Nie wiesz, które połączenia zostaną odebrane jako pierwsze. Może to być trudne do wyjaśnienia w tym miejscu, ale po prostu przeczytaj o rzeczy „Kontekst danych” w usługach RIA lubUsługi danych WCF . Więc kiedy mam do czynienia z linią aplikacji biznesowych, jest to dla mnie poważny problem. Opiera się to głównie na wydajności i łatwości konserwacji. Możesz tworzyć aplikacje bez kontekstu danych. To po prostu ułatwia pracę, szczególnie w Silverlight, WPF, a teraz w Windows 8 Metro. Posiadanie jednostek relacyjnych ładowanych do pamięci asynchronicznie i posiadanie dwóch powiązań jest naprawdę przyjemne.

Powiedziawszy to, czy to oznacza, że ​​pewnego dnia WebApi może obsługiwać „kontekst danych” na kliencie? Myślę, że tak. Ponadto przy większej liczbie narzędzi projekt programu Visual Studio może generować wszystkie metody CRUD na podstawie schematu bazy danych (lub Entity Framework).

Wiem też, że wspominam tylko o .NET do .NET Framework, jeśli chodzi o pracę z usługami danych WCF lub WebApi, ale jestem bardzo świadomy, że HTML / JS jest również głównym graczem. Właśnie wspomniałem o korzyściach, które znalazłem podczas korzystania z interfejsu użytkownika Silverlight lub kodu po stronie serwera ASP.NET itp. Uważam, że wraz z pojawieniem się „IndexedDB” w HTML5 / JavaScript, który ma „Kontekst danych” i Struktura LINQ w języku JavaScript może również stać się dostępna, dzięki czemu możliwość wykonywania zapytań w usługach OData z poziomu JavaScript będzie jeszcze łatwiejsza (można dziś używać DataJS z OData). Ponadto użycie KnockoutJS do obsługi MVVM i Binding w HTML / JS sprawi, że będzie to proste :)

Obecnie szukam platformy, której mam użyć. Byłbym szczęśliwy z jednego z nich, ale skłaniam się ku OData ze względu na fakt, że moja następna aplikacja dotyczy głównie Analytics (tylko do odczytu) i chcę bogatego, ekspresyjnego interfejsu API RESTful. Wierzę, że OData + WCF Data Services daje mi to, ponieważ WebApi obsługuje tylko $ take, $ skip, $ filter, $ orderby w przypadku kolekcji. NIE obsługuje projekcji, zawiera ($ expand) itp. Nie mam wielu „aktualizacji / usunięć / wstawień”, a nasze dane są dość relacyjne.

Mam nadzieję, że inni dołączą do dyskusji i podzielą się swoimi przemyśleniami. Nadal decyduję i chciałbym poznać inne opinie. Naprawdę uważam, że oba te frameworki są świetne. Zastanawiam się, czy musisz w ogóle wybierać, dlaczego nie użyć obu w razie potrzeby. Od klienta i tak chodzi o budowanie połączeń REST. Tylko myśl :)

Uważamy, że interfejs API sieci Web zapewnia odpowiednią platformę dla usług OData w przyszłości i jako taki będziemy inwestować przede wszystkim w tę platformę dla stosów serwerów OData. Będziemy oczywiście nadal umieszczać znaczne zasoby w podstawowych bibliotekach OData i kliencie, ale planujemy zmniejszyć inwestycje w usługi danych WCF jako stos do tworzenia usług OData.

Blog zespołu OData

Tak więc wydaje się, że teraz wszystko jest wystarczająco jasne

Zarówno interfejs API sieci Web, jak i usługi danych WCF obsługują OData po wyjęciu z pudełka. W przypadku usług danych WCF (WCFDS) jest to automatyczne. W przypadku interfejsu API sieci Web wróć IQueryablez kontrolera i oznacz metodę za pomocą [Queryable]. Dzięki temu uzyskasz $filterfunkcjonalność, o której mówiłeś. A jeśli zrobisz to w ten sposób, oba mogą automatycznie obsługiwać JSON w odpowiedzi, umieszczając accept=application/jsonnagłówek żądania. OData z WCFDS obsługuje kilka więcej słów kluczowych OData niż internetowy interfejs API (chociaż $expandprzychodzi mi na myśl tylko słowo kluczowe), ale jestem pewien, że czas temu zaradzi.

Zarówno klienci .NET, jak i strony HTML mogą łatwo wywoływać obie te alternatywy, ale jeśli lubisz LINQ i tworzysz klientów .NET, WCFDS można dodać do projektu jako odniesienie do usługi. Umożliwia to całkowite pominięcie całej działalności HTTP i bezpośrednie wysyłanie zapytań do kolekcji.

Najważniejsze jest to, że nic nie stoi na przeszkodzie, aby umieścić pliki .svc w projekcie ASP.Net MVC. To nie jest propozycja albo-albo. Dodanie usług danych do serwera pozwoli Ci zaoszczędzić na pisaniu wielu kontrolerów, ale nie przeszkodzi Ci w pisaniu dodatkowych kontrolerów, jeśli chcesz.

Innymi słowy :

Jeśli chcesz szybko udostępnić model danych (EDM lub w inny sposób) i nie potrzebujesz dużej ilości kodu lub logiki biznesowej, usługi danych WCF sprawiają, że jest to NAPRAWDĘ łatwe i byłoby dobrym punktem wyjścia.

Jeśli tworzysz interfejs API i po prostu chcesz udostępnić niektóre zasoby (i logikę) za pomocą składni zapytań OData lub formatowania, wówczas prawdopodobnie najlepszym miejscem do rozpoczęcia jest ASP.NET Web API .

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

Devaron przedstawił najbardziej pouczającą recenzję WCF vs Web Api, jakiej jeszcze nie znalazłem. Dzięki. Do tego stopnia, że ​​WCF jest zbyt złożone, powiem, że złożoność nie jest automatycznie wartością ujemną. Będziesz wdzięczny za przestrzeń do oddychania, jaką zapewni ci w przyszłości. Wyzwaniem, jak zawsze w przypadku narzędzi firmy Microsoft, jest to, że nie znamy ani nie kontrolujemy tej przyszłości. Miejmy nadzieję, że Microsoft skończy z bardziej ujednoliconym systemem i że pozostanie na rynku przez kilka lat.

Muszę też zbudować duży system i podkreśla mnie, że ścieżka nie jest bardziej przejrzysta. Planuję wstrzymać się jeszcze przez kilka miesięcy, aż wszystko się ułoży. Osobiście kibicuję dla datajs (sprawdź też JayData)

Ujmij to w najprostszy sposób, wycofaj się z podstawowego protokołu i spójrz na to z perspektywy programisty / użytkownika. Interfejs API sieci Web to pierwsza klasa oparta na protokole HTTP Rest Framework firmy Microsoft, a nie WCF. Oznacza to, że wszelkie brakujące funkcje i specyfikacje Rest zostaną dodane do potoku interfejsu API sieci Web, a niekoniecznie do WCF.

Tak, możesz zaimplementować je samodzielnie w programie WCF, ale jak jest napisane w zdaniu, musisz zaimplementować je samodzielnie.

Tak jak w przypadku dzisiejszego wdrożenia uwierzytelniania dwuskładnikowego dla internetowego interfejsu API zajmuje mniej niż 15 minut przy użyciu OWIN, który jest przede wszystkim pakietem nuget uwierzytelniania / autoryzacji, który rozpoczął się jako projekt open source.

Kiedy używasz stosu technologii, korzystanie z pierwszego stosu klasy dla Microsoft robi ogromną różnicę. Mógłbyś nawet opublikować niezliczoną ilość przykładowego kodu i projektów MS opublikowanych na Githubie, które możesz po prostu skopiować i rozpocząć swój własny projekt. To robi różnicę na każdym poziomie, dokumentacji, przykładach kodu, zestawie funkcji, wsparciu, pomocniczych interfejsach API, które nazwiesz.

Więc moja prosta rada dla Ciebie, jeśli chcesz tworzyć aplikacje oparte na protokole HTTP Restfull, używaj internetowego interfejsu API (lub ASP.NET Core w celu przenoszenia) i naprawdę trzymaj się z daleka od WCF. Jeśli protokół nie jest protokołem HTTP i naprawdę nie może być protokołem HTTP, użyj WCF.

To jest odpowiedź TL; DR na to pytanie.

WCF to szwajcarski scyzoryk do śrubokręta WEB API do komunikacji i przesyłania danych: WCF może zrobić wszystko, co może zrobić WEB API, ale jeśli potrzebujesz więcej (np. Używając protokołu TCP), najlepszym rozwiązaniem jest WCF.

Oto świetne porównanie .

WEB API

Powodem numer jeden dla korzystania z WEB API jest jego niewielka waga. Oznacza to, że jest prostszy w implementacji, łatwiejszy do nauczenia, łatwiejszy w utrzymaniu itp. Został specjalnie zaprojektowany dla sieci Web, która potrzebuje usług sieciowych REST zgodnych z protokołem HTTP. Robi to i robi to dobrze. Jeśli to wszystko, czego potrzebujesz, WEB API jest prawdopodobnie najlepszym rozwiązaniem.

Jest to również Open Source (jeśli ci zależy)

WCF

WCF po prostu robi o wiele więcej niż WEB API: obsługuje wiele protokołów transferu, wiele wzorców wymiany (WEB API wymaga integracji z SignalR lub Web Sockets), usługi SOAP można opisać w WSDL, ma dodatkowe funkcje bezpieczeństwa i nie tylko. Idź z WCF, jeśli potrzebujesz tej dodatkowej funkcji.

OData

OData jest po prostu

Otwarty protokół umożliwiający tworzenie i korzystanie z odpytywalnych i interoperacyjnych interfejsów API RESTful w prosty i standardowy sposób. źródło: http://www.odata.org/

Innymi słowy, na wysokim poziomie, to po prostu standaryzacja określonej gramatyki dla żądań HTTP RESTful. Który zapewni te same korzyści, co każdy protokół. Od co najmniej 2013 zarówno WCF, jak i WEB API pozwalają na używanie OData. Więc prawdopodobnie nie warto martwić się o OData.