2011-07-13 21 views
16

Mam rozwiązanie MVC, które obsługuje kilka tras dla usług Web API. W niektórych sytuacjach będę je wywoływał z JavaScript za pomocą prostego pobierania HTTP. W innych chcę wywołać je z jakiegoś kodu .NET, być może innej aplikacji MVC.Dodaj odwołanie do usługi Web API ASP.NET

Czy istnieje sposób dodania odwołania do usługi do tych punktów końcowych interfejsu Web API i czy oprzyrządowanie tworzy typy klientów proxy i CLR, tak jak w przypadku typowej usługi WCF? Wiem, że nie ma tutaj żadnego SOAP, ale przeczytałem, że jest to możliwe, po prostu nie jak.

Odpowiedz

15

Nie jest to usługa REST. Usługa REST nie udostępnia metadanych do tworzenia proxy za pomocą odwołania do usługi (z wyjątkiem usług danych WCF, które mają specjalną formę metadanych). Użyj klasy Web-API o nazwie HttpClient, aby zadzwonić do usługi.

+0

Dzięki za odpowiedź. Więc nie ma schematu metadanych jako takiego, ale czy myślisz, że można wywnioskować z odpowiedzi tak jak xsd dla XML. Dodanie referencji do usługi będzie wymagało wyprowadzenia jakiegoś schematu, zbudowania na tej podstawie klasy clr, a klient zasadniczo zrezygnuje z tej kolekcji. Czy to coś, co oprzyrządowanie może praktycznie wesprzeć, aby zapewnić elastyczność korzystania z tego typu usług w czasie projektowania? –

+0

To dość kiepska wymówka. Typowy scenariusz polega na tym, że dzwonisz do swojej własnej usługi - i zawsze masz metadane dla własnej usługi. Jest to tylko kwestia gorszego oprzyrządowania. Sprawy stają się gorsze, jeśli chcesz OData: wtedy będziesz musiał napisać swój własny dostawca linq, aby uzyskać ekspresję, którą posiadałeś ze starych dobrych usług WCF. Lepsze oprzyrządowanie może to zmienić. – John

+0

@John: Istnieje wiele stron UserVoice prowadzonych przez MS. Spróbuj zwiększyć żądanie (jeśli już nie istnieje), aby dodać obsługę opisów WADL lub WSDL2 dla usług REST. Gdy opis jest dostępny, możesz mieć pokolenie dla klienta. –

1

Nie bezpośrednio, ale z kilku przykładów, które widziałem, korzystanie z Web Api wymaga skonfigurowania ServiceContract. Wydaje się, że jeśli dodasz drugi interfejs kontraktu serwisowego z odpowiednimi atrybutami OperationContract & DataContract, możesz utworzyć punkt końcowy ze standardowym wiązaniem WCF wybranym przez użytkownika i jego pasującym punktem końcowym MEX. Usługa implementowałaby oba interfejsy, dzięki czemu dodatek Service Reference może uzyskać dokument WSDL ze standardowego punktu końcowego WCF.

+0

Jest kilka szczegółów do rozważenia, takich jak serializacja (powinny być takie same w obu przypadkach, aby uniknąć impedancji), zduplikowane atrybuty metod (te nie są kompatybilne między frameworkami), a także uwierzytelnianie i autoryzacja. Podejrzewam, że to kłopot nie warty korzyści, ale mimo wszystko jest to ciekawy pomysł. – John

8

Nie mamy żadnego standardowego mechanizmu do tego. REST dotyczy budowania systemów, które umożliwiają klientom ewoluowanie niezależnie od serwera. HTTP definiuje jednolity interfejs GET, PUT, POST, DELETE, itd., Dlatego nie ma potrzeby opisywania metody. Z obu powodów nie ma odpowiednika WSDL REST, lub powinienem powiedzieć, że nie ma odpowiednika, który naprawdę nabrał rozpędu wśród społeczności REST (tj. Istnieje WADL).

Punkt sprzężenia w usługach REST zależy od rodzaju nośnika/formatu body. W tym celu wspieramy mocno napisany mechanizm. W Web API wysyłamy HttpClient (HttpClient na Nuget), który pozwala ci wziąć typ CLR i przekształcić go w jakąś reprezentację. Po wyjęciu z pudełka obsługuje XML i JSON.

W ten sposób można utworzyć typ CLR i udostępnić go klientom, a następnie użyć HttpClient na kliencie.

Aby utworzyć sam typ, dostępnych jest również kilka opcji.

  1. Tworzenie go ręcznie
  2. Użyj „Wklej jako XML” narzędzie i funkcja automatycznego strona Pomoc Korzystanie Web API do kopiowania/wklejania.