Для опису RESTful можна сказати, що кожен ресурс має свій власний URI. Використовуючи HTTP GET, POST, PUT та DELETE, ми можемо працювати на цих ресурсах. Усі ресурси є представницькими. Той, хто хоче використовувати наші ресурси, може зробити це через браузер або клієнт REST.
Це головна ідея архітектури RESTful. Ця архітектура дозволяє послуги в Інтернеті. То навіщо цій архітектурі потрібен WADL? Що пропонує WADL, а що не стандартний HTTP? Чому WADL повинен існувати?
Відповіді:
Метою WADL є визначення контракту . Контракт визначає, як одна сторона може зателефонувати іншій.
Коли ви створюєте веб-додаток з нуля, вам не потрібні контракт і WADL .
Коли ви інтегруєте свою систему з іншою системою і можете чітко спілкуватися з командою розробників, вам не потрібні договір та WADL (адже ви можете зателефонувати, щоб все зрозуміти).
Однак коли ви інтегруєте складну корпоративну систему з кількома іншими складними корпоративними системами, що підтримуються декількома різними компаніями (або федеральними установами), тоді, повірте, ви хочете, щоб контракт на комунікацію був визначений якомога строгіше. Тоді вам потрібна WADL або Open Specification. Це дуже потрібно .
Люди зі слабким фоном підприємства, як правило, сприймають цілі ІТ як колекцію відокремлених веб-додатків, розроблених самостійно. Але реальність підприємств часом буває важкою. Іноді ви навіть не можете зателефонувати або написати людям, які розробляють додаток, з яким вам доводиться інтегрувати. Іноді ви спілкуєтесь із застарілою програмою, яка більше не підтримується - вона просто запускається, і вам потрібно зрозуміти, як правильно з нею спілкуватися. У таких умовах вам потрібен контракт, оскільки він рятує вашу дупу .
Насправді генерація клієнта є другорядною особливістю визначення контракту. Це просто іграшка. Контракт змушує поганих комунікаторів чітко повідомляти правила інтеграції. Це основна причина використовувати WADL або Open Specification або що завгодно.
Contract enforces bad communicators to communicate integration rules clearly.
Використання WADL означає, що ви просто можете бути досить люб’язними, щоб фактично визначити дані / документи, які ви передаєте туди-сюди. Скажімо, ви передаєте деякі XML-фрагменти, вони насправді можуть бути частиною визначеної схеми.
Використання DL для генерування коду для мене не дуже важливо. На мою суб’єктивну думку, важливим є те, що важливо мати офіційну угоду про взаємодію між діловими партнерами. Навіть якщо те, що передано , очевидно, це допомагає визначити, хто повинен щось виправити пізніше, якщо хтось змінить попередній інтерфейс.
Формат даних - це така ж частина інтерфейсу, як імена дієслів.
WADL звертається до людей, які походять із світу SOAP, де зазвичай використовується генератор коду для створення коду на стороні клієнта на основі WSDL. Я не думаю, що механізм корисний у REST, оскільки він створює клієнтський код, який пов'язаний з кінцевими точками сервера.
Я вважаю, що якщо ви належним чином визначаєте свої типи носіїв та використовуєте гіпермедіа всередині цих типів медіа, то не потрібно мати WADL. Опис доступних кінцевих точок міститься в самих визначеннях типу носія. І якщо ви зараз говорите собі, але application / xml не містить жодної інформації про доступні гіперпосилання, тоді я кажу BINGO. Ось чому я не думаю, що application / xml та application / json є відповідними типами носіїв для REST. Я не кажу, що не використовуйте XML або JSON, просто не використовуйте загальне ім'я типу носія.
Інше звернення WADL стосується документування послуг REST. На жаль, це веде розробників неправильним шляхом, оскільки WADL намагається задокументувати кінцеві точки на стороні сервера. Документування послуг REST має зосереджуватись переважно на типах носіїв. Розробник клієнта повинен мати можливість написати клієнта REST, не знаючи жодної URL-адреси, крім кореневої.
WADL дозволяє генерувати код, тести та документацію. Насправді є дуже корисні інструменти, що використовують WADL, деякі приклади ви можете побачити тут . Проблема "чистого" REST, як описано в дисертації Філдінга, полягає у написанні клієнтів, що підтримують Hypermedia (уявіть, наприклад, написання клієнтської програми на основі Java Swing). З WADL це завдання повністю автоматизовано, і це, на мій погляд, є величезною перевагою. Тестування стає набагато простішим.
Перш ніж я дам пояснення, дозвольте мені сказати, що більшість чистих екстремістів, що відпочивають, будуть висміювати це до кінців землі. Я з ними не погоджуюсь, бо я волів би щось зробити, але щоб ви знали.
WADL - це опис API веб-сервісу, трохи схожий на WSDL для веб-служб типу SOAP, який розроблений для того, щоб бути більш співзвучним інтерфейсам RESTful (щось, на що WSDL поганий).
З мого досвіду, основним використанням є створення генерального коду клієнта, який може викликати службу (зручно, якщо це дуже великий API, що буквально економить години роботи). Він також служить для документування REST-подібного інтерфейсу.
Коли ви бажаєте виставити послуги REST, найкращим способом є створення WADL та обмін із споживачем (подібно до WSDL у веб-сервісах, що базуються на SOAP). WADL використовується для опису послуги, що працює на місці.
WADL використовувати не потрібно. Але, якщо ви працюєте зі складною існуючою програмою і хочете реалізувати виклик служби REST, замінивши виклик служби EJB / SOAP, тоді ви дуже безпечно та корисно практикуєте використання WADL. Використовуючи WADL, генерує клієнтські заглушки Java, ви будете синхронізовані зі службою.
Ви можете генерувати заглушку Java на стороні клієнта, використовуючи файл WADL, за допомогою плагіна wadl2java maven.