Jaki jest powód stosowania WADL?

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

To, czy używasz DL do generowania kodu, nie jest dla mnie bardzo ważne. Moim subiektywnym zdaniem ważne jest formalne porozumienie w sprawie interfejsów między partnerami biznesowymi. Nawet jeśli to, co zostało przekazane jest oczywiste, to pomaga zidentyfikować, kto ma naprawić co później, jeśli ktoś zmieni poprzedni interfejs.

Format danych jest tak samo częścią interfejsu jak nazwy czasowników.

WADL odwołuje się do ludzi wywodzących się ze świata SOAP, gdzie do tworzenia kodu po stronie klienta bazującego na WSDL często używa się generatora kodu. Nie sądzę, aby ten mechanizm był przydatny w REST, ponieważ tworzy kod klienta, który jest sprzężony z punktami końcowymi serwera.

Wierzę, że jeśli poprawnie zdefiniujesz swoje typy multimediów i użyjesz hypermedii w tych typach multimediów, to nie jest konieczne posiadanie WADL. Opis dostępnych punktów końcowych znajduje się w definicjach typów nośników siebie. 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 rodzajami mediów do REST. Nie mówię, że nie używaj XML lub JSON, po prostu nie używaj ogólnej nazwy typu nośnika.

Drugi apel WADL ma na celu dokumentowanie usług wypoczynku. Niestety, prowadzi deweloperów na złą drogę, ponieważ WADL próbuje punkty końcowe po stronie serwera dokumentu. Dokumentowanie usług wypoczynkowych powinno koncentrować się przede wszystkim na rodzajach mediów. Programista Klienta powinien być w stanie napisać klienta REST bez znajomości żadnego adresu url innego niż adres główny.

WADL pozwala na generowanie kodu, testów i dokumentacji. W rzeczywistości jest kilka bardzo przydatnych narzędzi wykorzystujących WADL, możesz zobaczyć kilka przykładów tutaj. Problem z" czystym " odpoczynkiem, jak opisano w pracy doktorskiej Fieldinga, polega na pisaniu klientów wspierających Hypermedia (wyobraźmy sobie na przykład pisanie aplikacji klienckich opartych na Javie). Dzięki WADL to zadanie jest w pełni zautomatyzowane i jest to moim zdaniem ogromna zaleta. Testowanie staje się również o wiele łatwiejsze.

Zanim dam swoje wyjaśnienie, powiem, że większość czystych ekstremistów odpoczynku wyśmieje się z tego aż po krańce ziemi. Nie zgadzam się z nimi, bo wolałbym coś zrobić, ale tak dla twojej wiadomości.

WADL jest opisem API usług internetowych, trochę jak WSDL jest dla usług internetowych typu SOAP, który jest zaprojektowany, aby być bardziej dopasowany do interfejsów RESTful(coś WSDL jest słabe).

Z mojego doświadczenia wynika, że głównym zastosowaniem jest umożliwienie generowania kodu klienta, który może wywoływać usługa (przydatna, jeśli jest to bardzo duże API, które dosłownie oszczędza godziny pracy). Służy również do dokumentowania interfejsu przypominającego odpoczynek.

Reszta nic nie mówi o WADLU.

Jeśli chcesz ujawnić usługi REST ,najlepszym sposobem jest wygenerowanie WADL i udostępnienie go konsumentowi(podobnie jak WSDL w usługach internetowych opartych na SOAP).WADL jest używany do opisania usługi all in on place.

WADL nie jest konieczny 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, to jest bardzo bezpieczne i dobrą praktyką, że używasz WADL. Używając WADL generate client side java stubs, będziesz zsynchronizowany z usługą.

Możesz wygenerować java stub po stronie klienta używając pliku WADL za pomocą wtyczki wadl2java maven.