RESTful Services - еквівалент WSDL

Я читав про REST та SOAP, і розумію, чому впровадження REST може бути корисним за використання протоколу SOAP. Однак я все ще не розумію, чому у світі REST немає еквівалента "WSDL". Я бачив повідомлення, що "немає потреби" в WSDL або що це буде зайвим у світі REST, але я не розумію, чому. Чи не завжди корисно програмно прив’язати до визначення та створити проксі-класи замість ручного кодування? Я не хочу вступати у філософські дебати, просто шукаючи причину, по якій у REST немає WSDL, або чому вона не потрібна. Дякую.

Опис Web Application Language (WADL) в основному еквівалентна WSDL для RESTful послуг , але там було триваюче протиріччя, чи потрібно що - щось подібне на всіх.

Джо Грегоріо написав приємну статтю на цю тему, яку варто прочитати.

WSDL описує кінцеві точки служби. Клієнти REST не повинні підключатися до кінцевих точок сервера (тобто не повинні заздалегідь знати про це в URL-адресах). Клієнти REST з'єднуються на типах носіїв, які передаються між клієнтом та сервером.

Може мати сенс автоматично генерувати класи на клієнті, щоб обернути навколо повернених типів носіїв. Однак, як тільки ви починаєте створювати проксі-класи навколо взаємодії служб, ви починаєте затемнювати взаємодії HTTP і ризикуєте повернутися до моделі RPC.

RSDL прагне перетворити відпочинок як гіпермедію, іншими словами, він має більше інформації, ніж дескриптор послуги, такий як WSDL або WADL. Наприклад, він містить інформацію про навігацію, наприклад гіпертекст та гіперпосилання.

Наприклад, з огляду на поточний ресурс, у вас є набір основних посилань на інші пов’язані ресурси.

Однак я не знайшов клієнтів відпочинку, які підтримують цей формат, або рішень Rest Server з функцією автоматичного його створення.

Я думаю, що довгий шлях до висновку щодо цього. Див. Довгу історію HTML та W3C проти браузерів, ха-ха.

Детальніше про "Відпочинок як Гіпермедіа" дивіться: http://en.wikipedia.org/wiki/HATEOAS

Примітка: Рой Філдінг критикував ці тенденції в Рест Апіс без підходу гіпермідії: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Мій висновок: WADL тепер через кілька днів частіше зустрічається в тому, що програми відпочинку та інтеграції, такі як Camel CXF, вже підтримують WADL (генерувати та споживати), оскільки він схожий на WSDL, тому найпростіший для розуміння в цьому процесі міграції (SOAP to REST).

Давайте подивимось наступні глави;)

Чи не завжди корисно програмно прив’язати до визначення та створити проксі-класи замість ручного кодування?

Погодьтеся від усієї душі , ось чому я використовую Swagger.io

Swagger - це потужна система з відкритим кодом, що підтримується великою екосистемою інструментів, яка допомагає розробляти, створювати, документувати та споживати ваші RESTful API.

Отже, в основному я використовую Swagger для опису своїх моделей, кінцевих точок тощо, а потім використовую інші інструменти, такі як swagger-codegen, для створення проксі-класів, замість того, щоб кодувати його вручну.

Дивіться також: RAML

Існує RSDL (мова опису спокійних послуг), що еквівалентно WSDL. Наведена нижче URL-адреса описує практику http://en.wikipedia.org/wiki/HATEOAS та http://en.wikipedia.org/wiki/RSDL . Проблема в тому, що у нас є безліч інструментів для генерації коду з wsdl на java або зворотного. Але я не знайшов жодного інструменту для генерації коду з RSDL.

WSDL є розширюваним, щоб дозволити опис кінцевих точок та їх повідомлень незалежно від того, які формати повідомлень або мережеві протоколи використовуються для зв'язку

Однак REST використовує мережевий протокол за допомогою дієслів HTTP та URI для представлення стану об'єктів.

WSDL повідомляють вам, що якщо ви надішлете це повідомлення, ви виконаєте цю дію та отримаєте цей формат у результаті.

У REST, якщо я хотів створити новий профіль, я б використовував дієслово POSTіз змінними тіла JSON або сервера http, що описують мій профіль до URL/profile

POSTповинен повернути згенерований на стороні сервера ідентифікатор, використовуючи код стану 201 CREATEDта заголовок Location: *new_profile_id*(наприклад 12345)

Потім я можу виконувати оновлення, змінюючи стан /profile/12345використання дієслова HTTP POST, скажімо, змінити мою електронну адресу або номер телефону. Очевидно зміна стану віддаленого об'єкта.

GET поверне поточний статус /profile/12345

PUT зазвичай використовується для ідентифікатора, що генерується на стороні клієнта

DELETE, очевидно

HEAD, отримує статус без повернення тіла.

За допомогою REST він повинен самодокументуватись через добре розроблений API і, отже, бути простішим у використанні.

Це чудова стаття про REST. Це справді допомагає мені зрозуміти це теж.

Специфікація WSDL 2.0 також додала підтримку веб-служб REST. Кращий сценарій обох світів. Проблема в тому, що WSDL 2.0 ще не широко підтримується більшістю інструментів. WSDL 2.0 рекомендується W3C, WSDL1.1 не рекомендується W3C, але широко підтримується інструментами та розробниками. Посилання: http://www.ibm.com/developerworks/library/ws-restwsdl/

Мова опису веб-додатків (WADL) - це лексика XML, яка використовується для опису веб-служб RESTful.

Як і у випадку з WSDL, загальний клієнт може завантажувати файл WADL і бути негайно обладнаний для доступу до повної функціональності відповідної веб-служби.

Оскільки сервіси RESTful мають більш прості інтерфейси, WADL не є таким необхідним для цих служб, як WSDL для служб SOAP у стилі RPC.