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

94

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

сказ
источник
4
У меня такой же вопрос. Кажется, что с точки зрения клиентов успокаивающие сервисы намного сложнее использовать, чем WSDL-сервис.
w.donahue
4
Мне кажется, что если вы разоблачаете что-то простое, то WADL или WSDL вам не нужны. Но если вы раскрываете что-то настолько сложное, как SAP ... Я не могу представить себе, чтобы у вас не было какого-то отражения и пространства имен для обработки множества функций.
Brain2000,
Разве метод HTTP OPTIONS нельзя считать «эквивалентом», поскольку он должен предоставлять информацию о доступных методах и параметрах, необходимых для любых возможных действий?
Dim13i 08

Ответы:

44

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

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

Joschi
источник
1
Спасибо, Джоши. Я читал статьи, но второй не нашел слишком убедительным. Какие моменты, которые он затрагивает, были для вас наиболее ценными?
сказ
1
Возможно, стоит отметить, что .NET также имеет способ публикации метаданных ( msdn.microsoft.com/en-us/library/ms730243.aspx ). С учетом сказанного, большинство REST-сервисов, разработанных мною на крупных сайтах, включают в себя множество загружаемых клиентов, разработанных для основных языков программирования (Java, .NET, PHP и т. Д.). На мой взгляд, это накладывает большую нагрузку на поставщика услуг.
dana
4
@dana: Кажется, нет особого смысла писать сервис, который требует, чтобы вы также написали клиент?
BlueChippy
19

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

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

Даррел Миллер
источник
4
Не могли бы вы уточнить немного подробнее? Боюсь, я этого не понимаю. Спасибо.
сказ
1
Прокси-классы - это способ проверки машины во время компиляции. Без них у вас есть только документация, написанная вручную, и «проверка» на основе тестирования.
Эрик Грейндж
1
@EricGrange ... и все же этот подход до сих пор неплохо работал в Интернете.
Даррел Миллер,
1
@DarrelMiller зависит от того, что вы называете «хорошо сработало», это как в 80-х, когда все писали свои запросы из бумажных документов, так что это работает, но «хорошо»?
Эрик Грейндж
4
@BlueChippy Спецификации медиа-типа рассматриваются по старинке. Вы либо находите существующий синтаксический анализатор для спецификации, либо читаете спецификацию и пишете его самостоятельно. Важно отметить, что цель состоит в том, чтобы спецификации типов носителей можно было повторно использовать в API. Написание нового парсера для каждого API лишает смысла. REST, если все сделано правильно, дает очень долгосрочные преимущества независимой эволюции клиента и сервера.
Даррел Миллер
8

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).

Посмотрим следующие главы;)

Эдуардо Фабрицио
источник
8

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

Искренне согласен, поэтому я использую Swagger.io

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

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

См. Также: RAML

Алекс Ноласко
источник
Не знал, что Swagger тоже сделал это. Думал, что это просто документация / общая структура для REST API
Роберт Дандон
6

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

Ричард
источник
3

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

Родер
источник
2
Я бы сказал, что это ограничение REST гипермедиа, в большей степени, чем ограничение унифицированного интерфейса, устраняет необходимость в WSDL.
Даррел Миллер
3
Где вам найти "профиль"? Как вы оказываете помощь, если вместо одного у вас десятки? Все остальные сервисы полагаются на рукописные документы и написанные вручную API, которые трудоемки и подвержены ошибкам.
Эрик Грейндж
1
Я согласен с @EricGrange - пожалуйста, не могли бы вы объяснить, КАК вы знаете, какие объекты вы можете выполнять операции CRUD (L) НА ... если кто-то где-то не записывает?
BlueChippy 08
2

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

сверхновая звезда
источник
0

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

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

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

JSS
источник