Чтобы описать RESTful, мы можем сказать, что каждый ресурс имеет свой собственный URI. Используя HTTP GET, POST, PUT и DELETE, мы можем работать с этими ресурсами. Все ресурсы репрезентативные. Кто хочет использовать наши ресурсы, может сделать это через браузер или REST-клиент.
Это основная идея архитектуры RESTful. Эта архитектура позволяет предоставлять услуги в Интернете. Так зачем этой архитектуре WADL? Что предлагает WADL, чего нет в стандартном HTTP? Зачем нужен WADL?
Цель WADL - определить контракт. Контракт определяет, как одна сторона может позвонить другой.
Когда вы создаете веб-приложение с нуля, вам не нужен контракт и WADL.
Когда вы интегрируете свою систему с другой системой и можете четко общаться с их командой разработчиков, вам не нужен контракт и WADL (потому что вы можете позвонить по телефону, чтобы прояснить ситуацию).
Однако, когда вы интегрируете сложную корпоративную систему с несколькими другими сложными корпоративными системами, обслуживаемыми несколькими разными компаниями (или федеральными учреждениями), поверьте мне, вы хотите, чтобы договор связи был определен как можно более строго. Тогда вам понадобится WADL или открытая спецификация. Сильно нужно.
Люди со слабым корпоративным опытом склонны рассматривать ИТ в целом как набор отдельных веб-приложений, разработанных независимо. Но корпоративная реальность иногда бывает непростой. Иногда вы даже не можете позвонить или написать людям, разрабатывающим приложение, с которым вам нужно интегрироваться. Иногда вы общаетесь с устаревшим приложением, которое больше не обслуживается - оно просто запускается, и вам нужно выяснить, как с ним правильно взаимодействовать. В таких условиях нужен контракт, потому что он спасает вашу задницу.
На самом деле создание клиентов - это второстепенная особенность определения контракта. Это просто игрушка. Контракт заставляет плохих коммуникаторов четко сообщать правила интеграции. Это основная причина использовать WADL, открытую спецификацию или что-то еще.
Contract enforces bad communicators to communicate integration rules clearly.
- person hc_dev; 13.12.2020
Использование WADL подразумевает, что вы просто можете быть достаточно любезны, чтобы фактически определить данные / документы, которые вы передаете туда и обратно. Допустим, вы передаете некоторые фрагменты XML, они могут быть частью определенной схемы.
Для меня не очень важно, используете ли вы DL для генерации кода. По моему субъективному мнению, важно то, что важно иметь формальное соглашение о взаимодействии между деловыми партнерами. Даже если переданное очевидно, это помогает определить, кто и что должен исправить позже, если кто-то изменит предыдущий интерфейс.
Формат данных является такой же частью интерфейса, как и имена глаголов.
WADL обращается к людям из мира SOAP, где обычно используют генератор кода для создания кода на стороне клиента на основе WSDL. Я не думаю, что этот механизм полезен в REST, поскольку он создает клиентский код, связанный с конечными точками сервера.
Я считаю, что если вы правильно определяете свои медиа-типы и используете гипермедиа в этих медиа-типах, тогда нет необходимости иметь WADL. Описание доступных конечных точек содержится в самих определениях медиа-типов. И если вы сейчас говорите себе, но application / xml не содержит никакой информации о доступных гиперссылках, я говорю BINGO. Вот почему я не думаю, что application / xml и application / json являются подходящими медиа-типами для REST. Я не говорю, что не используйте XML или JSON, просто не используйте имя общего типа мультимедиа.
Другое обращение WADL - документальное оформление служб REST. К сожалению, это ведет разработчиков по ложному пути, поскольку WADL пытается задокументировать конечные точки на стороне сервера. Документирование REST-сервисов должно быть сосредоточено в первую очередь на медиа-типах. Разработчик клиента должен иметь возможность написать клиент REST, не зная никакого URL-адреса, кроме корневого.
WADL позволяет создавать код, тесты и документацию. На самом деле существует несколько очень полезных инструментов, использующих WADL, некоторые примеры вы можете увидеть здесь. Проблема с «чистым» REST, как описано в диссертации Филдинга, заключается в написании клиентов, поддерживающих Hypermedia (представьте, например, написание клиентского приложения на основе Java Swing). С WADL эта задача полностью автоматизирована, и, на мой взгляд, это огромное преимущество. Тестирование тоже становится проще.
Прежде чем я дам свое объяснение, позвольте мне сказать, что самые чистые экстремисты REST будут высмеивать его до края земли. Я не согласен с ними, так как я бы предпочел что-то сделать, но просто чтобы вы знали.
WADL - это описание API веб-службы, немного похожее на WSDL для веб-служб типа SOAP, которое спроектировано для большей согласованности с интерфейсами RESTful (в чем WSDL не справляется).
По моему опыту, в основном это используется для создания клиентского кода, который может вызывать службу (удобно, если это очень большой API, который буквально экономит часы работы). Он также служит для документирования REST-подобного интерфейса.
REST ничего не говорит о WADL.
Если вы хотите предоставить службы REST, лучший способ - создать WADL и поделиться с потребителем (аналогично WSDL в веб-службах на основе SOAP). WADL используется для описания службы на месте.
WADL использовать не обязательно. Но если вы работаете со сложным существующим приложением и хотите реализовать вызов службы REST, заменив вызов службы EJB / SOAP, тогда использование WADL является очень безопасным и хорошим методом. Используя WADL для создания клиентских java-заглушек, вы будете синхронизированы со службой.
Вы можете сгенерировать java-заглушку на стороне клиента, используя файл WADL с помощью плагина maven wadl2java.
