Почему медленное освоение WADL?

Я изучал WADL и мне интересно, почему он не получил более широкого распространения?

Учитывая скорость, с которой растет использование REST, я удивлен, что больше разработчиков не используют его.

Есть ли фундаментальный недостаток в его дизайне, не соответствует ли он культуре, которая обычно окружает веб-сервисы RESTful, или это что-то совершенно другое?


rest wadl
person Allain Lalonde    schedule 17.01.2009    source источник

Ответы (2)


arrow_upward
17
arrow_downward

Я думаю, что основная причина, по которой WADL не набирает популярности, заключается в том, что он может вернуть к жизни все те проблемы, которые у нас были с SOAP и WSDL. Для меня аспект функциональной совместимости является наиболее важным аспектом веб-сервисов.
Следуя RESTful способу использования чистых стандартов HTTP, вы получаете функциональную совместимость «бесплатно». Как только вам понадобится документ для описания сервисов, будут разные клиентские фреймворки (или разные серверные фреймворки), которые будут интерпретировать этот документ по-разному. Как только разные фреймворки автоматически сгенерируют код из WADL, вам снова придется решать проблемы совместимости.

Отсутствие стандартов — это слабость и сила RESTful, давайте дадим шанс простому подходу. (хотя нам очень нравится автоматическая генерация кода :-))

person LiorH    schedule 17.01.2009
comment
Я не согласен с тем, что взаимодействие бесплатно при использовании REST. REST не обеспечивает взаимодействие волшебным образом, не так, как WADL надеялся бы обеспечить. Я понимаю, что существуют проблемы взаимодействия (некоторые называют это несоответствием импеданса) при отображении, скажем, XSD в класс Java или XSD в C#. Но это не обязательно верно для всех таких подходов к картированию. В частности, XSD намного сложнее, чем нужно, чтобы поддерживать случай взаимодействия 80% для веб-сервисов. Если WADL будет достаточно скромным в своих целях, он может обеспечить реальную ценность с низким риском подводных камней. - person Cheeso; 22.01.2010
comment
Я согласен с Cheeso, REST ничего не дает «бесплатно». У вас все еще есть «некоторая работа», чтобы убедиться, что вы имеете дело с яблоками (а не с апельсинами), особенно с полезной нагрузкой данных (независимо от того, существует ли HTTP или нет). REST также создает проблемы при сопоставлении с различными целями «языки/наборы инструментов». Это создает дополнительные возможности для несоответствия импеданса между двумя конечными точками (особенно, когда каждая конечная точка не находится под управлением одной точки). - person gto406; 13.04.2011
comment
Я не думаю, что это является причиной низкой адаптации (на самом деле я могу поспорить о справедливости и этой причины, кроме той). Причиной низкой адаптации wadl в моем понимании может быть его использование в архитектуре всего решения. Очень немногие думают, что REST и Enterprise SOA вместе. Службы REST часто размещаются на внешних интерфейсах для использования JavaScript или мобильных приложений. Адаптация REST в архитектуре MicroServices SOA небольшая, но она расширяется, это подтолкнет к таким вещам, как WADL и автоматическая генерация клиентов. - person Saumitra R. Bhave; 08.07.2015
comment
Согласен с @Cheeso (и gto406) Предложение Ничто в REST is for Free не защищено авторским правом или авторским правом? ;) Простой, приятный (как говорят подписчики), у остальных тоже есть проблема с программным обеспечением, первое, что я думаю: проблема с датой в библиотеках MS REST / JSON (следующее кодирование специальных символов в любительских наивных реализациях) - person Jacek Cz; 23.09.2015
comment
Я удивлен, что все еще получаю комментарии к этому ответу ... люди все еще рассматривают WADL? - person LiorH; 12.10.2015
comment
Отсутствие генерации клиентов - облом :( - person AlikElzin-kilaka; 13.01.2016

arrow_upward
10
arrow_downward

«REST на практике: гипермедиа и системная архитектура» Джима Уэббера, Саваса Парастатидиса и Яна Робинсона упоминает четыре проблемы:

  1. WADL заранее использует статическое представление веб-приложения, где в Интернете используются типы мультимедиа и ссылки для контрактов.
  2. Инструментарий WADL обеспечивает тесную связь клиентских и сервисных абстракций. Ресурсы, рекламируемые сервисом, становятся моделью предметной области клиента.
  3. WADL не дает никаких подсказок о порядке взаимодействия с рекламируемыми ресурсами.
  4. WADL часто дублирует метаданные, доступные из ресурсов.

Пункты 1 и 2 являются аргументами в отношении динамических и статических привязок клиентов. При использовании WADL разработчик службы должен быть осторожен с обратной совместимостью схемы по мере изменения службы. Без WADL клиент должен гибко интерпретировать ответы.

Пункт 3 касается рабочего процесса. WADL не документирует порядок, в котором должны вызываться API. Ответы службы как WADL, так и не-WADL предлагают ключи к упорядочению по ссылкам, если служба реализована в соответствии с HATEOAS практика.

Пункт 4 утверждает, что результаты HEAD и OPTIONS могут не соответствовать определению WADL. На практике ни один из этих методов редко реализуется или используется.

Многие реализации REST быстрые и грязные. Службу REST легко реализовать только для моего использования. Когда мне нужно создать клиент для службы, предоставляемой другой командой, мне нужна документация. Чем формальнее, тем лучше. Документация, читаемая в коде, такая как WADL, была бы лучше всего.

Мои опасения как разработчика клиента:

  1. Как узнать, какие параметры запроса и заголовки поддерживаются?
  2. Как я могу найти документацию о типе носителя запроса или ответа? Даже если это тип носителя, зарегистрированный в IANA, мне все равно понадобятся схемы запроса/ответа.
person Chas    schedule 10.08.2012
comment
Любопытно, что люди думают в наши дни, учитывая популярность таких вещей, как Swagger. - person Alex; 12.07.2017