RESTful Services - Эквивалент WSDL

Question

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Разве не всегда полезно программно связываться с определением и создавать прокси-классы вместо ручного кодирования?

Согласитесь от всего сердца, поэтому я использую Swagger.io

Swagger - это мощная платформа с открытым исходным кодом, поддерживаемая большой экосистемой инструментов, которая помогает вам проектировать, создавать, документировать и использовать ваши API-интерфейсы RESTful.

Поэтому в основном я использую Swagger для описания своих моделей, конечных точек и т. Д., А затем я использую другие инструменты, такие как swagger-codegen , чтобы генерировать прокси-классы вместо того, чтобы вручную его кодировать.

См. Также: RAML

Answer 4

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

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

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

Я думаю, что для этого есть долгий путь. Посмотрите длинную историю HTML и W3C против браузеров.

Для получения более подробной информации об отдыхе, как Hypermedia, смотрите его: http://en.wikipedia.org/wiki/HATEOAS

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

Мое заключение: теперь дни WADL более распространены, чем фреймворки отдыха и интеграции, такие как Camel CXF, уже поддерживают WADL (генерирование и использование), поскольку он похож на WSDL, поэтому его легче понять в этом процессе миграции (SOAP на ОТДЫХ).

Давайте посмотрим на следующие главы;)

Answer 5

Существует RSDL (язык описания сервисов), который эквивалентен WSDL. URL-адрес ниже описывает его практику http://en.wikipedia.org/wiki/HATEOAS и http://en.wikipedia.org/wiki/RSDL. Проблема в том, что у нас есть много инструментов для генерации кода из WSDL в Java или наоборот. Но я не нашел никакого инструмента для генерации кода из RSDL.

Answer 6

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

Answer 7

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. Это действительно помогает мне понять это.

Answer 8

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

Как и в случае WSDL, универсальный клиент может загрузить файл WADL и сразу же получить доступ к полной функциональностисоответствующий веб-сервис.

Поскольку сервисы RESTful имеют более простые интерфейсы, WADL не так необходим для этих сервисов, как WSDL для сервисов SOAP в стиле RPC.