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

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

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

8 ответов


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

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

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

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

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

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


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

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

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


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

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

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


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


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

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

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



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


WADL не обязательно использовать. Но если вы работаете со сложным существующим приложением и хотите реализовать вызов службы REST, заменив вызов службы EJB/SOAP, то использование WADL является очень безопасной и хорошей практикой. С помощью WADL генерировать клиентские Java заглушки вы будете синхронизированы со службой.

вы можете создать Java-заглушку на стороне клиента, используя файл WADL с помощью плагина wadl2java maven.