В чем причина использования WADL?

Чтобы описать RESTful, мы можем сказать, что каждый ресурс имеет свой собственный URI. Используя HTTP GET, POST, PUT и DELETE, мы можем работать с этими ресурсами. Все ресурсы являются репрезентативными. Тот, кто хочет использовать наши ресурсы, может сделать это через браузер или клиент REST.

Это основная идея архитектуры RESTful. Эта архитектура позволяет пользоваться услугами в Интернете. Итак, зачем нужна эта архитектура WADL? Что предлагает WADL для этого стандартного HTTP-протокола? Почему WADL должен существовать?

Ответ 1

Цель WADL - определить контракт. Контракт указывает, как одна сторона может позвонить другому.

Когда вы создаете веб-приложение с нуля, вам не нужен контракт и WADL.

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

Однако, когда вы интегрируете сложную корпоративную систему с несколькими другими сложными корпоративными системами, поддерживаемыми несколькими различными компаниями (или федеральными учреждениями), тогда поверьте мне, вы хотите заключить контракт на связь как можно более строго, Затем вам понадобится WADL или Open Specification. Нужно это плохо.

Люди со слабым корпоративным фоном, как правило, видят весь ИТ как коллекцию отделенных веб-приложений, разработанных независимо. Но корпоративная реальность иногда бывает жесткой. Иногда вы даже не можете звонить или писать людям, разрабатывающим приложение, с которым вы должны интегрироваться. Иногда вы общаетесь с устаревшим приложением, которое больше не поддерживается - оно просто запускается, и вам нужно выяснить, как правильно общаться с ним. В таких условиях вам нужен контракт, потому что он сохраняет вашу задницу.

На самом деле генерация клиента является второстепенной особенностью определения контракта. Это просто игрушка. Контракт обязывает плохих коммуникаторов четко сообщать правила интеграции. Это основная причина использования WADL или Open Specification или что-то еще.

Ответ 2

Использование WADL подразумевает, что вы просто можете быть достаточно любезны, чтобы фактически определить данные/документы, которые вы передаете взад и вперед. Скажем, вы передаете некоторые фрагменты XML, они могут быть частью определенной схемы.

Независимо от того, используете ли вы DL для генерации кода, для меня это не очень важно. В моем субъективном мнении важно, чтобы было важно иметь официальное соглашение об интерфейсах между деловыми партнерами. Даже если то, что передано, очевидно, это помогает определить, кто должен исправить то, что позже, если кто-то изменит предыдущий интерфейс.

Формат данных является такой же частью интерфейса, как и имена глаголов.

Ответ 3

WADL обращается к людям, поступающим из мира SOAP, где обычно используется генератор кода для создания клиентского кода на основе WSDL. Я не думаю, что этот механизм полезен в REST, поскольку он создает клиентский код, который связан с конечными точками сервера.

Я считаю, что если вы правильно определяете свои медиа-типы и используете гипермедиа в этих медиа-типах, тогда нет необходимости иметь WADL. Описание доступных конечных точек содержится в самих определениях типа мультимедиа. И если вы сейчас говорите себе, но приложение /xml не содержит никакой информации о доступных гиперссылках, то я говорю BINGO. Поэтому я не думаю, что application/xml и application/json являются подходящими медиа-типами для REST. Я не говорю, что я не использую XML или JSON, просто не используйте общее имя типа мультимедиа.

Другая апелляция WADL предназначена для документирования служб REST. К сожалению, это приводит разработчиков к неправильному пути, поскольку WADL пытается документировать конечные точки на стороне сервера. Документирование служб REST должно фокусироваться прежде всего на медиа-типах. Клиент-разработчик должен иметь возможность писать клиент REST, не зная какого-либо URL-адреса, кроме корневого URL-адреса.

Ответ 4

WADL позволяет генерировать код, тесты и документацию. На самом деле есть несколько очень полезных инструментов, использующих WADL, здесь вы можете увидеть несколько примеров здесь. Проблема с "чистым" REST, как описано в диссертации Fielding, заключается в написании клиентов, поддерживающих Hypermedia (например, для написания клиентского приложения на основе Java Swing). С WADL эта задача полностью автоматизирована, и это огромное преимущество, на мой взгляд. Тестирование становится еще проще.

Ответ 5

Прежде чем дать свое объяснение, позвольте мне сказать, что самые чистые экстремисты REST будут высмеивать это до конца земли. Я не согласен с ними, так как я скорее сделаю что-то, но просто знаю.

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

Основное использование в моем опыте - позволить вам генерировать клиентский код, который может вызвать услугу (удобно, если это очень большой API, что буквально экономит часы работы). Он также служит для документирования REST-подобного интерфейса.

Ответ 6

REST ничего не указывает о WADL.

Ответ 7

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