Zaczynam grać z usługami WebApi i Rest. Do tej pory zawsze rozwijałem interfejsy API SOAP.ASP.Net MVC4 WebApi proxy
Moje pytanie to jest coś równoległego do proxy w MVC4 WebApi lub tylko w koncepcji SOAP. Jeśli nie, to jak klienci znają pełny opis funkcji internetowych, które im eksponuję.
Dzięki
Pewnie myśli opisu usługi WSDL, który nie istnieje w WebAPI jako takie. Teraz widzę, że dodałeś także tag REST do pytania i chciałbym podkreślić, że WebAPI nie wymusza praktyk REST.
REST jest ostatnio w trakcie dyskusji, ale wydaje mi się, że wszyscy zgadzają się, że nie definiuje ona żadnej usługi podobnej do usługi wsdl.
Uważa jednak wymagać, aby dokumenty własnym opisywania i zachęca do publikowania możliwe transfery państwowych oraz linki do powiązanych dokumentów więcej informacji tutaj: http://en.wikipedia.org/wiki/HATEOAS
reszta to zupełnie inna bestia niż mydło, ponieważ w rzeczywistości nie chcesz, abyś wysyłał komendy do i z serwera inne niż podstawowe potrzebne do uzyskania/aktualizacji/.. zasobów, ale pełny opis tego wykracza poza zakres tego postu :-)
To powiedziawszy, Technologia webAPI sama w sobie nie ma żadnych zastrzeżeń w tym zakresie i byłoby całkowicie możliwe, aby świadczyć usługi w pełnym zakresie i powiązana struktura podobna do WSDL.
Mogę polecić ten projekt, użyłem go do kilku projektów i działa dobrze.
PS: Jestem współpracownikiem projektu, chociaż nie mam jeszcze żadnego kodu.
Podejrzewam Noc Walker jest mniej zainteresowany WSDL i bardziej zainteresowany tym, jak utworzyć klasę proxy w spożywającej aplikacji. Plik WSDL jest używany przez narzędzia do automatycznego generowania proxy. Rozumiem, że nie ma opublikowanej definicji, ale czy WebAPI zawiera narzędzia programistyczne do automatycznego generowania klas proxy, które może wywoływać kod? –
W tej chwili nie AFAIK, chociaż nie ma powodu, dla którego nie można go w jakiś sposób dodać. Ale z moją odpowiedzią chciałem również wskazać, że "czysty" interfejs REST API nie powinien wymagać tych klas proxy, ponieważ jedynymi "metodami" są czasowniki HTTP. Potrzebujesz wiedzy o domenie, aby zrozumieć zasoby i stany REST, ale odpowiedzi API powinny być samoopisujące i powinny wskazywać dalsze opcje dostępne dla każdego napotkanego zasobu. – Dirk
REST nie zastępuje w miejscu SOAP! wymaga innego sposobu myślenia o sposobie publikowania informacji i funkcji. – Dirk