Почему медленное поглощение WADL?

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

"REST in Practice: Hypermedia and Systems Architecture" Джима Уэббера, Саваса Парастатидиса и Иана Робинсона упоминает четыре проблемы:

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

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

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

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

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

Мои проблемы в качестве разработчика-клиента:

  • Как узнать параметры запроса и заголовки, которые поддерживаются?
  • Как найти документацию о типе запроса или типа ответа? Даже если это зарегистрированный тип IANA, мне все равно понадобятся схемы запроса/ответа.