В чем причина использования WADL?
для описания RESTful можно сказать, что каждый ресурс имеет свой собственный URI. Используя HTTP GET, POST, PUT и DELETE, мы можем работать с этими ресурсами. Все ресурсы являются репрезентативными. Тот, кто хочет использовать наши ресурсы, может сделать это через браузер или клиент REST.
Это основная идея спокойной архитектуры. Эта архитектура позволяет предоставлять услуги в интернете. Так почему же эта архитектура нуждается в WADL? Что предлагает WADL, чего не делает стандартный HTTP? Почему WADL нужно существуют?
8 ответов:
цель WADL заключается в определении контракт. Контракт определяет, как одна сторона может вызвать другую.
при создании веб-приложения с нуля, вам не нужен контракт и WADL.
когда вы интегрируете свою систему с другой системой, и вы можете четко общаться с их командой разработчиков, вам не нужен контракт и WADL (потому что вы можете сделать телефонный звонок, чтобы сделать вещи четкий.)
однако, когда вы интегрируете сложную корпоративную систему с несколькими другими сложными корпоративными системами, поддерживаемыми несколькими различными компаниями (или федеральными учреждениями), тогда поверьте мне вы хотите чтобы контракт на связь был определен как можно более строго. тогда вам нужно WADL или открыть спецификацию. Нужно это очень.
люди со слабым корпоративным фоном, как правило, видят все это как набор разделенных веб-страниц приложения разрабатываются самостоятельно. Но корпоративная реальность иногда жесткая. Иногда вы даже не можете позвонить или написать людям, разрабатывающим приложение, с которым вы должны интегрироваться. Иногда вы общаетесь с устаревшим приложением, которое больше не поддерживается-оно просто работает, и вам нужно выяснить, как правильно с ним общаться. в таких условиях вам нужен контракт, потому что он спасает свою задницу.
на самом деле создание клиента является второстепенной особенностью определение договора. Это просто игрушка. Контракт принуждает плохих коммуникаторов четко сообщать правила интеграции. Это основная причина использовать WADL или открытую спецификацию или что-то еще.
использование WADL подразумевает, что вы просто можете быть достаточно любезны, чтобы фактически определить данные / документы, которые вы передаете взад и вперед. Скажем, вы передаете некоторые фрагменты XML,они могут быть частью определенной схемы.
используете ли вы DL для генерации кода, для меня не очень важно. Что важно, на мой субъективный взгляд, так это то, что важно иметь формальное соглашение о взаимодействии между деловыми партнерами. Даже если то, что передается - это очевидно, это помогает определить, кто должен исправить то, что позже, если кто-то изменит предыдущий интерфейс.
формат данных является такой же частью интерфейса, как и имена глаголов.
WADL обращается к людям, приходящим из мира SOAP, где обычно используется генератор кода для создания кода на стороне клиента на основе WSDL. Я не думаю, что этот механизм полезен в REST, поскольку он создает клиентский код, который связан с конечными точками сервера.
Я считаю, что если вы правильно определяете свои медиа-типы и используете гипермедиа в этих медиа-типах, то нет необходимости иметь WADL. Описание доступных конечных точек содержится в типе носителя сами определения. И если вы сейчас говорите себе, но приложение / xml не содержит никакой информации о доступных гиперссылках, то я говорю Бинго. Вот почему я не думаю, что application/xml и application/json являются подходящими типами носителей для REST. Я не говорю, что не используйте XML или JSON, просто не используйте общее имя типа носителя.
другая апелляция WADL предназначена для документирования услуг REST. К сожалению, это приводит разработчиков по неправильному пути, как WADL пытается документировать конечные точки на стороне сервера. Документирование служб REST должно быть сосредоточено в первую очередь на медиа-типах. Разработчик клиента должен иметь возможность написать клиент REST, не зная никакого url-адреса, кроме корневого url-адреса.
WADL позволяет создавать код, тесты и документацию. На самом деле есть несколько очень полезных инструментов, использующих WADL, вы можете увидеть некоторые примеры здесь. Проблема с "чистым" отдыхом, как описано в диссертации Филдинга, заключается в написании клиентов, поддерживающих гипермедиа (представьте себе написание клиентского приложения на основе Java Swing, например). С русло, эта задача полностью автоматизирована, и это огромное преимущество на мой взгляд. Тестирование тоже становится намного проще.
прежде чем я дам свое объяснение, позвольте мне сказать, что самые чистые экстремисты покоя будут высмеивать его до конца земли. Я не согласен с ними, так как я бы предпочел что-то сделать, но просто чтобы вы знали.
WADL-это описание API веб-службы, немного похожее на WSDL для веб-служб типа SOAP, которые предназначены для большей настройки с интерфейсами RESTful (что-то WSDL плохо).
Это в мой опыт, чтобы позволить вам генерировать клиентский код это может вызвать службу (удобно, если это очень большой API, который буквально экономит часы работы). Он также служит для документирования интерфейса REST-like.
когда вы хотите предоставить услуги REST ,лучший способ-создать WADL и поделиться с потребителем(подобно WSDL в веб-службах на основе SOAP).WADL используется для описания службы все на месте.
WADL не обязательно использовать. Но, если вы работаете со сложным существующим приложением, и вы хотите реализовать вызов службы REST, заменив вызов службы EJB/SOAP, то это очень безопасная и хорошая практика, которую вы используете WADL. С помощью WADL генерировать заглушки java на стороне клиента вы будете синхронизированы со службой.
вы можете сгенерировать Java-заглушку на стороне клиента с помощью файла WADL с помощью плагина wadl2java maven.
Comments