Я читал о REST и SOAP и понимаю, почему реализация REST может быть более выгодной, чем использование протокола SOAP. Однако я до сих пор не понимаю, почему в мире REST нет эквивалента WSDL. Я видел сообщения, в которых говорилось, что WSDL «не нужен» или что он был бы лишним в мире REST, но я не понимаю, почему. Разве не всегда полезно программно связываться с определением и создавать прокси-классы вместо ручного кодирования? Я не хочу вдаваться в философские дискуссии, просто ищу причину, по которой в REST нет WSDL, или почему он не нужен. Спасибо.
94
Ответы:
Язык описания веб-приложений (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 для описания своих моделей, конечных точек и т. Д., А затем я использую другие инструменты, такие как 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.
источник