Usługi RESTful - odpowiednik WSDL

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.

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ć.

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.

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;)

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

Istnieje RSDL (restful service description language), który jest odpowiednikiem WSDL. Poniższy URL opisuje jego praktykę http://en.wikipedia.org/wiki/HATEOAS i http://en.wikipedia.org/wiki/RSDL . Problem polega na tym, że mamy dużo narzędzi do generowania kodu z wsdl do java lub odwrotnie. Ale nie znalazłem żadnego narzędzia do generowania kodu z RSDL.

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ć.

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/

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.