Jaki jest powód korzystania z WADL?

Aby opisać RESTful, możemy powiedzieć, że każdy zasób ma swój własny identyfikator URI. Wykorzystując HTTP GET, POST, PUT i DELETE możemy operować na tych zasobach. Wszystkie zasoby są reprezentatywne. Kto chce skorzystać z naszych zasobów, może to zrobić za pośrednictwem przeglądarki lub klienta REST.

To główna idea architektury RESTful. Ta architektura umożliwia usługi w Internecie. Dlaczego więc ta architektura potrzebuje WADL? Co oferuje WADL, czego nie oferuje standardowy HTTP? Dlaczego WADL musi istnieć?

Celem WADL jest zdefiniowanie umowy . Umowa określa, w jaki sposób jedna strona może zadzwonić do drugiej.

Kiedy tworzysz aplikację internetową od podstaw, nie potrzebujesz umowy i WADL .

Kiedy integrujesz swój system z innym systemem i możesz jasno komunikować się z ich zespołem programistycznym, nie potrzebujesz umowy i WADL (ponieważ możesz wykonać telefon, aby wszystko było jasne).

Jeśli jednak integrujesz złożony system korporacyjny z kilkoma innymi złożonymi systemami korporacyjnymi obsługiwanymi przez kilka różnych firm (lub instytucji federalnych), to uwierz mi, że chcesz, aby umowa komunikacyjna była zdefiniowana tak ściśle, jak to możliwe. Następnie potrzebujesz WADL lub Open Specification. Potrzebuję tego bardzo .

Osoby o słabym doświadczeniu w przedsiębiorstwie zwykle postrzegają całe IT jako zbiór oddzielnych aplikacji internetowych tworzonych niezależnie. Ale rzeczywistość biznesowa jest czasami trudna. Czasami nie możesz nawet zadzwonić lub napisać do osób tworzących aplikację, z którą musisz się zintegrować. Czasami komunikujesz się ze starszą aplikacją, która nie jest już obsługiwana - po prostu działa i musisz dowiedzieć się, jak prawidłowo się z nią komunikować. W takich warunkach potrzebujesz kontraktu, bo to ratuje tyłek .

W rzeczywistości generowanie klientów jest drugorzędną cechą definicji umowy. To tylko zabawka. Kontrakt wymusza na złych komunikatorach jasne przekazywanie zasad integracji. To jest główny powód, dla którego warto korzystać z WADL lub Open Specification lub czymkolwiek.

Korzystanie z WADL oznacza, że ​​możesz być na tyle łaskawy, aby faktycznie zdefiniować dane / dokumenty, które przesyłasz tam iz powrotem. Załóżmy, że przekazujesz fragmenty XML, które w rzeczywistości mogą być częścią zdefiniowanego schematu.

To, czy używasz DL do generowania kodu, nie jest dla mnie bardzo ważne. W mojej subiektywnej opinii ważne jest, aby mieć formalną umowę dotyczącą interfejsów między partnerami biznesowymi. Nawet jeśli to, co zostało przekazane, jest oczywiste, pomaga zidentyfikować, kto musi później naprawić, jeśli ktoś zmieni poprzedni interfejs.

Format danych jest w takim samym stopniu częścią interfejsu, jak nazwy czasowników.

WADL przemawia do ludzi pochodzących ze świata SOAP, gdzie często używa się generatora kodu do tworzenia kodu po stronie klienta w oparciu o WSDL. Nie sądzę, aby ten mechanizm był przydatny w REST, ponieważ tworzy kod klienta, który jest połączony z punktami końcowymi serwera.

Uważam, że jeśli właściwie zdefiniujesz swoje typy mediów i użyjesz hipermediów w ramach tych typów mediów, to nie jest konieczne posiadanie WADL. Opis dostępnych punktów końcowych zawarty jest w samych definicjach typów mediów. A jeśli teraz mówisz sobie, ale application / xml nie zawiera żadnych informacji o dostępnych hiperłączach, to mówię BINGO. Dlatego uważam, że application / xml i application / json nie są odpowiednimi typami mediów dla REST. Nie mówię, że nie używaj XML ani JSON, po prostu nie używaj ogólnej nazwy typu nośnika.

Drugi apel WADL służy do dokumentowania usług REST. Niestety, prowadzi to programistów na złą ścieżkę, ponieważ WADL próbuje udokumentować punkty końcowe po stronie serwera. Dokumentowanie usług REST powinno skupiać się przede wszystkim na typach mediów. Programista klienta powinien móc napisać klienta REST bez znajomości adresu URL innego niż adres główny.

WADL umożliwia generowanie kodu, testów i dokumentacji. Właściwie istnieje kilka bardzo przydatnych narzędzi wykorzystujących WADL, możesz zobaczyć kilka przykładów tutaj . Problem z „czystym” RESTem, jak opisano w rozprawie Fieldinga, polega na pisaniu klientów obsługujących Hypermedia (wyobraź sobie na przykład pisanie aplikacji klienckiej opartej na Java Swing). W WADL to zadanie jest całkowicie zautomatyzowane i moim zdaniem jest to ogromna zaleta. Testowanie również staje się o wiele łatwiejsze.

Zanim wyjaśnię, pozwólcie mi powiedzieć, że większość czystych ekstremistów REST wyszydzi go na krańce ziemi. Nie zgadzam się z nimi, bo wolałbym coś zrobić, ale żebyś wiedział.

WADL to opis API usługi sieciowej, trochę jak WSDL dla usług sieciowych typu SOAP, który został zaprojektowany tak, aby był bardziej dostrojony do interfejsów RESTful (coś, w czym WSDL jest kiepski).

Z mojego doświadczenia wynika, że ​​jego głównym zastosowaniem jest umożliwienie generowania kodu klienta, który może wywołać usługę (przydatne, jeśli jest to bardzo duży interfejs API, który dosłownie oszczędza godziny pracy). Służy również do dokumentowania interfejsu podobnego do REST.

REST nie określa nic na temat WADL.

Jeśli chcesz udostępnić usługi REST, najlepszym sposobem jest wygenerowanie WADL i udostępnienie go konsumentowi (podobnie jak WSDL w usługach sieciowych opartych na SOAP). WADL służy do opisu usługi w miejscu.

WADL nie jest konieczne do użycia. Ale jeśli pracujesz ze złożoną istniejącą aplikacją i chcesz zaimplementować wywołanie usługi REST, zastępując wywołanie usługi EJB / SOAP, wtedy korzystanie z WADL jest bardzo bezpieczne i dobre. Korzystając z WADL generując kody java po stronie klienta, będziesz zsynchronizowany z usługą.

Możesz wygenerować kod JavaScript po stronie klienta za pomocą pliku WADL za pomocą wtyczki wadl2java maven.