2010-11-06 3 views
71

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

+2

У меня такой же вопрос. По-видимому, с точки зрения клиентов, услуги, обслуживаемые клиентами, гораздо сложнее использовать услугу WSDL. –

+3

Мне кажется, что если вы разоблачаете что-то простое, тогда вам не нужны WADL или WSDL. Но если вы разоблачаете нечто сложное, как SAP ... Я не могу понять, что у меня нет какого-то отражения и пространства имен, чтобы справиться с множеством функциональности. – Brain2000

+0

Не может ли метод HTTP OPTIONS рассматриваться как «эквивалентный», поскольку он должен предоставлять информацию о доступных методах и параметрах, необходимых для любых возможных действий? – Dim13i

ответ

33

Web Application Description Language (WADL) в основном эквивалентен WSDL для сервисов RESTful, но существует постоянная разногласия по поводу того, требуется ли вообще что-то подобное.

Joe Gregorio написал a nice article about that topic, который стоит прочитать.

+1

Спасибо Joschi. Я читал статьи, но не нашел второго слишком убедительным. Какие пункты, на которые он обращался, вы считаете наиболее ценными? – skaz

+1

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

+2

@dana: Кажется, не слишком много написано о службе, которая требует от вас также написать клиенту? – BlueChippy

15

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

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

+2

Можете ли вы подробнее рассказать? Боюсь, я этого не понимаю. Благодарю. – skaz

+0

Попробуйте это http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven –

+1

Прокси-классы - это способ проверки машины во время компиляции. Без них у вас есть только письменные документы и тестовая «проверка». –

1

WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate

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

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

В ОСТАЛЬНЫХ, если бы я хотел, чтобы создать новый профиль, я бы использовать глагол POST с телом JSON или HTTP-сервера переменных, описывающих мой профиль в URL /profile

POST должен вернуться на стороне сервера генерируется идентификатор, используя код состояния 201 CREATED и заголовок Location: *new_profile_id* (например, 12345)

затем я могу выполнять обновления, изменяющие состояние /profile/12345 с использованием HTTP глагола POST, скажем, изменить свой адрес электронной addresss или номер телефона. Очевидно, изменение состояния удаленного объекта.

GET возвратит текущее состояние /profile/12345

PUT обычно используется для клиентской стороны генерируется ID

DELETE, очевидный

HEAD, получает статус без возвращения тела.

С REST он должен быть самодокументирован с помощью хорошо продуманного API и, следовательно, более прост в использовании.

This is a great article НА ОТДЫХ. Это действительно помогает мне это понять.

+2

Я бы сказал, что это гипермедиа-ограничение REST, более того, чем унифицированное ограничение интерфейса, которое устраняет необходимость в WSDL. –

+3

Где именно находится "profile"? Как вы предоставляете помощь, если вместо одного у вас есть десятки? Все остальное обслуживание там основано на рукописных документах и ​​написанных вручную API, которые являются трудоемкими и подверженными ошибкам. –

+1

Я согласен с @EricGrange - пожалуйста, не могли бы вы объяснить, КАК вы знаете, какие сущности вы можете выполнять CRUD (L) операции ON ... если кто-то ничего не записывает? – BlueChippy

0

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

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

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

5

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

6

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

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

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

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

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

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

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

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

1

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

4

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

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

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

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

См. Также: RAML