Службы RESTful - эквивалент WSDL

Я читал о REST и SOAP и понимаю, почему реализация REST может быть более выгодной, чем использование протокола SOAP. Однако я до сих пор не понимаю, почему в мире REST нет эквивалента WSDL. Я видел сообщения, в которых говорилось, что WSDL «не нужен» или что он был бы лишним в мире REST, но я не понимаю, почему. Разве не всегда полезно программно связываться с определением и создавать прокси-классы вместо ручного кодирования? Я не хочу вдаваться в философские дискуссии, просто ищу причину, по которой в REST нет WSDL, или почему он не нужен. Спасибо.

Язык описания веб-приложений (WADL) в основном эквивалентен WSDL для служб RESTful, но до сих пор ведутся споры о том, нужно ли вообще что-то подобное.

Джо Грегорио написал хорошую статью на эту тему, которую стоит прочитать.

WSDL описывает конечные точки службы. Клиенты REST не должны быть связаны с конечными точками сервера (т. Е. Не должны заранее знать об URL-адресах). Клиенты REST связаны с типами носителей, которые передаются между клиентом и сервером.

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

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

Например, для текущего ресурса у вас есть набор ссылок на другие связанные ресурсы.

Однако я не нашел Rest Clients, которые поддерживают этот формат, или Rest Server Solutions с функцией его автоматического создания.

Я думаю, что до выводов еще далеко. См. Длинную историю HTML и W3C против браузеров lol.

Чтобы узнать больше о Rest, как Hypermedia, посмотрите его: http://en.wikipedia.org/wiki/HATEOAS

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

Мой вывод: сейчас WADL более распространен, чем платформы Rest и интеграции, такие как Camel CXF, уже поддерживают WADL (генерировать и использовать), потому что он похож на WSDL, поэтому его легче всего понять в этом процессе миграции (SOAP в 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.