WCF vs ASP .Net Web API

93

Jakie są wady i zalety korzystania z każdej technologii?

Interfejs WCF Web Api jest teraz scalony z Asp.net Web API Asp.net obsługuje teraz własny hosting.

Nadal wyobrażam sobie, że jeśli chcę ujawnić wiele schematów protokołów dla tej samej operacji, nadal skłaniałbym się do WCF lub czy punkt końcowy Mvc też to zrobić?

Czy nowy interfejs API sieci Web Asp.Net udostępnia Wsdl? Jeśli nie, w jaki sposób klient dowie się, jaka operacja jest dla niego dostępna?

Prawdopodobnie najlepszą cechą Mvc jest spoiwo modelarskie. Jak solidny jest odpowiednik WCF?

Czy ktoś może mi powiedzieć, jakie korzyści przynosi interfejs API sieci Web Asp.net? WCF wydaje się w przeważającej mierze bardziej wydajnym / skalowalnym wyborem, imo. Jedyną rzeczą, którą Mvc Web Api ma w modelu WCF, jest prawdopodobnie łatwość programowania, ale oznacza to przysadzistość, jeśli ostatecznie stanie się poważnym ograniczeniem projektowym w przyszłości.

wcf asp.net-mvc-4 asp.net-web-api Alwyn
źródło
15
Tytuł tego pytania wydaje mi się nieco mylący. Tytuł brzmi „MVC 4 vs Wcf Web Api”, ale wydaje się, że pytanie dotyczy bardziej WCF vs ASP .Net Web API. Z tytułu wydawało mi się, że porównywany jest standardowy framework MVC 4 (kontrolery, modele, widoki) vs framework ASP .Net Web API. Czy ktoś jeszcze uważa ten tytuł za mylący?
BruceHill,

Odpowiedzi:

72

Najpierw proponuję przeczytać mój post na ten temat: http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my- dwa centy na temat.aspx

Odnośnie twojego pytania o WSDL - ponieważ WebApi nie używa SOAP, nie wymaga WSDL i nie eksportuje go. Możesz użyć Hypermedia, aby zwrócić zasoby z listą możliwych adresów URL działań (potraktuj to jako samoopisujący się zasób)

IdoFlatow
źródło
6
To bardzo, bardzo dobry opis. Najlepszy, jaki kiedykolwiek widziałem. Ale teraz jestem bardziej zdezorientowany niż kiedykolwiek. WebApi dodaje tak wiele, ale brak możliwości ujawnienia innego punktu końcowego wydaje się bardzo ograniczający. Gdybyś miał klienta, który może używać mydła, będzie on teraz zmuszony do zbudowania akcji i przeanalizowania wyniku ręcznie, gdy mydło mogłoby wygenerować dla niego cały kontekst. Zablokujesz im również bardziej zaawansowaną funkcję Soap, taką jak niezawodna sesja i transakcja kwasowa ... westchnij.
Alwyn
2
@Alwyn - myślę, że wszystkie wspomniane przez Ciebie fakty są prawdziwe i dlatego nie powinny Cię mylić, a raczej pomóc w podjęciu decyzji - Web API ma swoje zalety, ale jeśli Twoja usługa musi być ujawniona z wielu punktów końcowych, w tym innych protokołów, czy masz silną potrzebę funkcji automatycznego generowania lub klient mydlanych zaawansowanych funkcji - to może być rozważenie, dlaczego wolą nad WCF Web API
BornToCode
@BornToCode: Kod klienta może być generowany automatycznie za pomocą WebAPI. Możesz utworzyć plik json Swagger przy użyciu kodu WebAPI. Ten plik json może być następnie używany przez generator kodu, taki jak swagger-codegen, do tworzenia kodu klienta w wielu językach docelowych.
nieumyślnie pozostawiono puste
@unintentionallyleftblank - IMHO Automatyczne generowanie kodu klienta za pośrednictwem WCF jest jeszcze bardziej „przyjazne dla użytkownika” niż przez interfejs API sieci Web.
BornToCode
15

Wybór zależy od tego, co chcemy robić.

  1. ASP.NET Web API to struktura do tworzenia usług innych niż SOAP tylko za pośrednictwem protokołu HTTP - więc nie ma więcej protokołów transportowych dostępnych przy użyciu tej struktury.
  2. WCF / Windows Communication Foundation to framework do wymiany komunikatów opartych na SOAP - tutaj używamy wielu protokołów transportowych: HTTP, TCP, nazwanych potoków, MSMQ itp.

Nie jestem pewien, który z nich ma lepszą wydajność pod względem ilości danych, może WCF, ponieważ możemy używać niskich protokołów. Wszelkie uwagi są mile widziane.

Junior Mayhé
źródło
2
Bez obrazy, ale HTTP to tylko protokół warstwy aplikacji. Nie ma żadnych nieodłącznych ograniczeń co do tego, jakie protokoły warstwy transportowej mogą być używane.
smwikipedia
8

Interfejs API sieci Web programu WCF koncentruje się głównie na implementacjach REST. Jeśli konfigurujesz implementację REST, standardowe bity WCF są trochę uciążliwe. Jeśli konfigurujesz usługi RESTful, interfejs API sieci Web WCF będzie znacznie przyjemniejszy. Jeśli konfigurujesz usługi SOAP, interfejs API sieci Web WCF nie jest Twoim najlepszym przyjacielem i lepiej jest używać WCF dla swoich usług.

Gregory A Beamer
źródło
2
Tak, konfiguracje są uciążliwe, ale jest to jednorazowy koszt konfiguracji. Gdy to zrobisz, możesz prawie skopiować i wkleić zachowanie / punkt końcowy do innej usługi. W większości przypadków wystarczy otagować nowe operacje za pomocą WebGet. Z drugiej strony, jeśli kiedykolwiek pojawi się klient, który chce używać Soap + Wsdl, to tylko zmiana konfiguracji, w przeciwieństwie do kodu + wdrożenie + QA + reszta. Więc w jaki sposób Mvc Web Api jest lepszy?
Alwyn
1
Jeśli znasz już WCF, możesz kontynuować tę ścieżkę. Oprócz tego, o czym wspomniałem, istnieją pewne wewnętrzne ulepszenia REST w interfejsie API sieci Web WCF (nie mam przed sobą listy), ale albo może działać i nie spędziłbym tygodni na refaktoryzacji, jeśli masz mnóstwo usługi pracy, zwł. ponieważ w myśleniu nastąpiła pewna zmiana paradygmatu. W przypadku przyszłych prac rozważę jednak interfejs API sieci Web WCF. Ale jestem z WCF Web API od jakiegoś czasu, więc mogę być stronniczy.
Gregory A Beamer
0

Używaj WCF dla witryn intranetowych / B2B n Web API dla witryn B2C / C2C / internetowych ... SOAP / XML nadal jest standardem komunikacji wewnątrz firm n to nie odejdzie !!!

A_Var
źródło