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

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

Ответ 2

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

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

Ответ 3

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

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

Тем не менее, я не нашел клиентов для отдыха, которые поддерживают этот формат или Rest Server Solutions, с возможностью автоматического его создания.

Я думаю, что есть большой путь для заключения об этом. Смотрите длинную историю HTML и W3C vs Browsers LOL.

Подробнее о Rest как 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 to REST).

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

Ответ 4

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

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

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

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

Смотрите также: RAML

Ответ 5

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

Ответ 6

WSDL расширяема, чтобы разрешать описание конечных точек и их сообщений независимо от того, какие форматы сообщений или сетевые протоколы используются для связи

Однако REST использует сетевой протокол с помощью HTTP-глаголов и URI для представления состояния объектов.

WSDLs расскажут вам об этом месте, если вы отправите это сообщение, вы выполните это действие и вернете этот формат в результате.

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

Ответ 7

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

Ответ 8

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

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

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