Usługi RESTful - odpowiednik WSDL


95

Czytałem o REST i SOAP i rozumiem, dlaczego wdrożenie REST może być korzystne w porównaniu z użyciem protokołu SOAP. Jednak nadal nie rozumiem, dlaczego w świecie REST nie ma odpowiednika „WSDL”. Widziałem posty mówiące, że WSDL „nie jest potrzebny” lub że byłby zbędny w świecie REST, ale nie rozumiem dlaczego. Czy nie zawsze warto programowo wiązać się z definicją i tworzyć klasy proxy zamiast ręcznego kodowania? Nie mam zamiaru wdawać się w debatę filozoficzną, po prostu szukam powodu, dla którego nie ma WSDL w REST lub dlaczego nie jest potrzebny. Dzięki.


4
Mam to samo pytanie. Wydaje się, że z punktu widzenia klienta usługi spoczynkowe są znacznie trudniejsze w użyciu niż usługa WSDL.
donahue,

4
Wydaje mi się, że jeśli ujawniasz coś prostego, nie potrzebujesz WADL ani WSDL. Ale jeśli ujawniasz coś tak złożonego jak SAP ... Nie mogę pojąć, że nie mam jakiejś refleksji i przestrzeni nazw do obsługi mnóstwa funkcji.
Brain2000

Czy metoda HTTP OPTIONS nie może być uznana za „równoważną”, ponieważ powinna dostarczać informacji o dostępnych metodach i parametrach potrzebnych do ewentualnego działania?
Dim13i

Odpowiedzi:


44

Opis Web Application Language (WADL) jest w zasadzie równoważne WSDL dla usług REST, ale nie było ciągłym kontrowersja, czy coś takiego jest w ogóle potrzebne.

Joe Gregorio napisał na ten temat fajny artykuł, który warto przeczytać.


1
Dzięki Joschi. Przeczytałem artykuły, ale drugi nie był zbyt przekonujący. Które punkty, które on poruszył, uważasz za najbardziej wartościowe?
skaz

1
Warto zauważyć, że .NET ma również sposób na publikowanie metadanych ( msdn.microsoft.com/en-us/library/ms730243.aspx ). Mając to na uwadze, większość usług REST, które widziałem opracowane przez duże witryny, zawiera różnorodne klienty do pobrania opracowane dla głównych języków programowania (Java, .NET, PHP itp.). Moim zdaniem nakłada to duże obciążenie na usługodawcę.
dana

4
@dana: Wydaje się, że nie ma sensu pisać usługi, która wymaga, abyś pisał również do klienta?
BlueChippy

19

WSDL opisuje punkty końcowe usługi. Klienci REST nie powinni być łączeni z punktami końcowymi serwera (tj. Nie powinni być z wyprzedzeniem świadomi adresów URL). Klienci REST są sprzężeni na typach nośników, które są przesyłane między klientem a serwerem.

Sensowne może być automatyczne generowanie klas na kliencie w celu zawijania zwracanych typów nośników. Jednak gdy tylko zaczniesz tworzyć klasy proxy wokół interakcji usług, zaczniesz zaciemniać interakcje HTTP i ryzykujesz degenerację z powrotem w kierunku modelu RPC.


4
Czy możesz rozwinąć trochę więcej? Obawiam się, że tego nie rozumiem. Dzięki.
skaz

1
Klasy proxy to sposób na walidację maszyny w czasie kompilacji. Bez nich masz tylko ręcznie napisane dokumenty i "walidację" opartą na testach.
Eric Grange,

1
@EricGrange ... a jednak to podejście jak dotąd działa całkiem nieźle w sieci.
Darrel Miller,

1
@DarrelMiller zależy od tego, co nazywasz „działało dobrze”, to jest tak, jak w latach 80-tych, kiedy wszyscy zapisywali swoje interopy z papierowych dokumentów, więc to działa, ale „dobrze”?
Eric Grange

4
@BlueChippy Specyfikacje typu mediów są traktowane w staroświecki sposób. Albo znajdujesz istniejący parser dla specyfikacji, albo czytasz specyfikację i sam ją napiszesz. Ważne jest, aby pamiętać, że celem jest, aby specyfikacje typu mediów mogły być ponownie używane w różnych interfejsach API. Pisanie nowego parsera dla każdego API mija się z celem. REST, gdy zostanie wykonany prawidłowo, zapewnia bardzo długoterminowe korzyści niezależnej ewolucji klienta i serwera.
Darrel Miller

8

RSDL ma na celu odwrócenie spoczynku jak hipermedia, innymi słowy, zawiera więcej informacji niż deskryptor usługi, taki jak WSDL lub WADL. Na przykład zawiera informacje o nawigacji, takie jak hipertekst i hiperłącza.

Na przykład, biorąc pod uwagę bieżący zasób, masz ustawione łącza systemu operacyjnego do innych powiązanych zasobów.

Jednak nie znalazłem Rest Clients, które obsługują ten format, ani Rest Server Solutions z funkcją automatycznego generowania.

Myślę, że do wyciągnięcia wniosków na ten temat jest długa droga. Zobacz długą historię HTML i W3C kontra przeglądarki lol.

Aby uzyskać więcej informacji na temat Rest like Hypermedia, zobacz: http://en.wikipedia.org/wiki/HATEOAS

Uwaga: Roy Fielding krytykował te tendencje w Rest Apis bez podejścia hipermidii: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Mój wniosek: Teraz dni, WADL jest bardziej powszechny niż struktury Rest and Integration Framework, takie jak Camel CXF, które już obsługują WADL (generuj i konsumuj), ponieważ jest podobny do WSDL, dlatego jest najłatwiejszy do zrozumienia w tym procesie migracji (SOAP do REST).

Zobaczmy kolejne rozdziały;)


8

Czy nie zawsze warto programowo wiązać się z definicją i tworzyć klasy proxy zamiast ręcznego kodowania?

Zgadzam się z całego serca, dlatego używam Swagger.io

Swagger to potężna platforma open source wspierana przez duży ekosystem narzędzi, które pomagają projektować, budować, dokumentować i wykorzystywać interfejsy API RESTful.

Zasadniczo używam Swaggera do opisywania moich modeli, punktów końcowych itp., A następnie używam innych narzędzi, takich jak swagger-codegen, do generowania klas proxy zamiast ręcznego kodowania.

Zobacz też: RAML


Nie wiedziałem, że Swagger też to zrobił. Myślałem, że to tylko dokumentacja / ogólny szkielet dla interfejsów API REST
Robert Dundon


3

WSDL jest rozszerzalny, aby umożliwić opis punktów końcowych i ich komunikatów niezależnie od formatów komunikatów lub protokołów sieciowych używanych do komunikacji

Jednak REST używa protokołu sieciowego przy użyciu zleceń HTTP i identyfikatora URI do reprezentowania stanu obiektów.

WSDL mówią ci w tym miejscu, że jeśli wyślesz tę wiadomość, wykonasz tę akcję i w rezultacie odzyskasz ten format.

W REST, gdybym chciał stworzyć nowy profil, użyłbym czasownika POSTz treścią JSON lub zmiennych serwera http opisujących mój profil do adresu URL/profile

POSTpowinien zwrócić identyfikator wygenerowany po stronie serwera, używając kodu stanu 201 CREATEDi nagłówka Location: *new_profile_id*(na przykład 12345)

Mogę wtedy przeprowadzić aktualizacje, zmieniając stan /profile/12345używania czasownika HTTP POST, na przykład zmienić mój adres e-mail lub numer telefonu. Oczywiście zmiana stanu zdalnego obiektu.

GET zwróci bieżący stan pliku /profile/12345

PUT jest zwykle używany jako identyfikator generowany po stronie klienta

DELETE, oczywiste

HEAD, otrzymuje status bez zwracania treści.

W przypadku REST powinien on samodokumentować się za pomocą dobrze zaprojektowanego interfejsu API, a tym samym łatwiejszy w użyciu.

To świetny artykuł na temat REST. To też naprawdę pomogło mi to zrozumieć.


2
Twierdziłbym, że to ograniczenie hipermedialne REST, bardziej niż jednolite ograniczenie interfejsu, eliminuje potrzebę WSDL.
Darrel Miller

3
Gdzie można znaleźć „profil”? Jak zapewniasz pomoc, skoro zamiast jednej masz dziesiątki? Cała reszta usług polega na odręcznych dokumentach i ręcznie napisanych interfejsach API, które są pracochłonne i podatne na błędy.
Eric Grange,

1
Zgadzam się z @EricGrange - czy mógłbyś wyjaśnić SKĄD wiesz, na jakich obiektach można wykonywać operacje CRUD (L) ... chyba że ktoś gdzieś to zapisuje?
BlueChippy

2

W specyfikacji WSDL 2.0 dodano również obsługę usług sieciowych REST. Najlepszy scenariusz z obu światów. Problem polega na tym, że WSDL 2.0 nie jest jeszcze powszechnie obsługiwany przez większość dostępnych narzędzi. WSDL 2.0 jest zalecany przez W3C, WSDL1.1 nie jest zalecany przez W3C, ale jest szeroko obsługiwany przez narzędzia i programistów. Ref: http://www.ibm.com/developerworks/library/ws-restwsdl/


0

Język opisu aplikacji sieci Web (WADL) to słownik XML używany do opisywania usług internetowych zgodnych z REST.

Podobnie jak w przypadku WSDL, ogólny klient może załadować plik WADL i natychmiast uzyskać dostęp do pełnej funkcjonalności odpowiedniej usługi sieciowej.

Ponieważ usługi RESTful mają prostsze interfejsy, WADL nie jest tak potrzebne dla tych usług, jak WSDL dla usług SOAP w stylu RPC.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.