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

Projektuję aplikację rozproszoną, która będzie składać się z usług REST i różnych klientów (Silverlight, iOS, Windows Phone 7 itp.). Byłem gotowy podjąć decyzję o wdrożeniu moich usług REST przy użyciu usług danych WCF (OData), ale teraz interfejs API sieci Web MVC 4 podważył mnie.

To, co podobało mi się w OData, to zapytania URI i możliwości hipermedia, które otrzymujesz za darmo. Nie podobało mi się gadatliwość ładunku OData; wiele niepotrzebnych znaków nadchodzi przez drut.

To, co podoba mi się w interfejsie API sieci Web, to to, że ładunki są znacznie bardziej zwięzłe i ma możliwość wysyłania zapytań OData przez OData, jednak wydaje się, że brakuje hipermediów (przynajmniej od razu po wyjęciu z pudełka). Mój szef naciska również na interfejs API sieci Web, ponieważ „moce, które są w Microsoft, wspierają go, a OData nie zyskuje trakcji”.

Mam więc dwa pytania:

1) Czy ktoś może komentować tworzenie kopii zapasowej / trakcji interfejsu API sieci Web i OData?

2) Czy oczekuje się, że interfejs API sieci Web będzie natywnie obsługiwał hipermedia do czasu wydania, czy też są jakieś gotowe implementacje lub przykłady, na które powinienem zwrócić uwagę?

Dzięki!

Web API robi odata. Zobacz post na blogu Scotta Guthrie . Konkretnie:

Skład zapytania: Interfejs API sieci Web umożliwia łatwą obsługę zapytań za pośrednictwem konwencji adresów URL OData. Po zwróceniu typu IQueryable z interfejsu API sieci Web platforma automatycznie zapewnia obsługę zapytań OData, ułatwiając wdrażanie stronicowania i sortowania.

Sądzę również, że w wielu przypadkach ta sama klasa może być tradycyjną klasą WCF i klasą Web API, zdecydowanie nie wykluczają się wzajemnie.

Interfejs API sieci Web wykorzystuje natywnie protokół HTTP. Odata jest standardem otwartym przyjętym przez wielu dużych graczy. Mogę mówić tylko z własnego doświadczenia związanego z zabawą z Odatą, a także z odkrywaniem interfejsu API sieci Web i przeprowadzaniem badań.

OData jest fajna, ponieważ jest faktycznym standardem. Możesz łatwo utworzyć bazę danych i udostępnić ją przez HTTP. Oznacza to, że możesz przechodzić przez strukturę tabeli bez żadnej konfiguracji (mówię to luźno). Możesz także uruchamiać zapytania za pośrednictwem adresu URL, które mogą zawierać lekkie LINQ:

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

To jest prawdopodobnie dobre lub złe. Uwierzytelnianie jest standardem i zostało zbudowane.

Interfejs API sieci Web jest bardziej interesujący z mojej perspektywy. Wykorzystał on funkcjonalność HTTP (komunikaty o błędach itp.) I jest nieco bardziej „natywny” dla prawdziwych żądań RESTful. Naprawdę nie bawiłem się zbytnio… Ale czytałem i słyszałem, że MVC i Web API mogą kiedyś zostać „zamężne”, znowu, może dobre, może złe…

Kiedy bawiłem się OData, utworzyłem Przechowywany Proc, Mapowałem go do powierzchni encji, skonfigurowałem silny typ powrotu, a następnie podłączyłem go do żądania adresu URL i BANG, moje żądanie RESTful jest mapowane na mój zapisany wynik proc. To było dość proste i udało mi się zdobyć dokładnie to, czego potrzebowałem.

Podsumowując , nie miałem okazji grać z WCF API zbyt szczegółowo, ale powiedziałbym, że jest to droga do rozwoju klienta, ponieważ jest to bardziej purystyczne podejście do REST. Jeśli będziesz wykonywać mniej więcej „proste” połączenia w obie strony i odzyskiwać „Wyświetl modele”, zapewni to bardziej natywną interakcję.

Z drugiej strony. Jeśli będziesz składać złożone (ish) zapytania dotyczące danych na podstawie interakcji klienta i chcesz „zbudować” logikę zapytania i przekazać ją jako parametr, wtedy Odata może działać.

Patrzę na to, jeśli potrzebuję ujawnić moje dane w formacie strukturalnym (co oznacza strukturę tabeli / relacji), a następnie wysłać zapytanie bezpośrednio do klienta, wtedy Odata będzie działać najlepiej. Jest również dobry do umożliwienia „innym” dostępu do danych (z odpowiednim uwierzytelnianiem itp.), Dlatego jest zgodny z protokołem OData

Jeśli chcesz żądań RESTful, w których dyktujesz adres URL (/ produkty / zamówienia / 22, i tworzysz złożone „zestawy wyników” z „ukrytego” zarządzanego kodu i struktury danych ORAZ możesz również skorzystać z komunikatów odpowiedzi HTTP, Interfejs API sieci Web byłby prawdopodobnie najlepszym wyborem.

znowu wszystko to od badań i zabawy. Nie wdrożyłem ani w scenariuszu produkcyjnym / w pełni wydanym. Myślę, że oboje będą mieli swoje mocne i słabe strony, a na pewno pewne nakładanie się

Z hipermedialnego punktu widzenia zdecydowanie Web API. OData, która jest oparta na AtomPub, to tylko sposób na ujawnienie bazy danych za pomocą HTTP, otrzymujesz tylko ograniczony zestaw predefiniowanych transferów stanu (CRUD). Z drugiej strony usługa hipermedia jest jak aplikacja dostosowana do klienta. Dzięki interfejsowi API sieci Web możesz osadzić wszystkie potrzebne linki, a także możesz użyć składni zapytania OData. W rzeczywistości najlepszym rozwiązaniem hipermedialnym w stosie Microsoft jest ASP.NET MVC, jeśli chcesz używać HTML jako formatu podstawowego.