Этот вопрос немного длинный, пожалуйста, потерпите меня.В REST я думаю, что нам не нужен WADL или IDL.А точнее то, что неявно охватывало бы его концепцию.Я думаю об этом, когда мы (люди) путешествуем по сети, когда мы впервые заходим на сайт, мы не знаем, какие услуги он предоставляет.Вы обнаружите тех, кто находится на домашней странице html (или на странице карты сайта в разделе справки) или, может быть, просто в главном меню на главной странице.Если вы проведете аналогию, домашняя страница или карта сайта для нас, людей, - это то, что WSDL для WS- * или WADL для службы REST.Только то, что его так же, как любой другой контент HTML.Я думаю, что в REST следующее - хороший способ сделать что-то, соблюдая парадигму HATEOS.Иметь ресурс верхнего уровня (или по умолчанию), в котором перечислены ссылки на другие ваши ресурсы.В качестве примера библиотеки, скажем RestLibrary.com/, это может быть что-то вроде:
<root xmlns:lib="http://librarystandards.com/libraryml">
<resource class="lib:book">
<link type="application/vnd.libraryml+xml" template="mylib.com/book/{isbn}" />
<link type="application/vnd.libraryml+xml" rel="add" href="mylib.com/book" method="POST" />
<link type="application/vnd.libraryml+xml" rel="update" template="mylib.com/book/{isbn}" method="PUT" />
</resource>
<resource class="lib:bookList">
<link template="mylib.com/book?keywords={keywords}" type="application/vnd.openlibrary+xml" rel="search" />
</resource>
</root>
Обратите внимание, что предполагается, что тип носителя "application / vnd.libraryml + xml" является определенным стандартом или (можетбыть просто частной лексикой) с именем libraryml.Также клиент должен уметь понимать этот ресурс «домашней страницы» (элементы root, resource и link).Это та часть, которую можно использовать вместо WADL: абстрактный словарь, который должен быть понятен любому клиенту.Вы можете использовать существующий стандарт, например, Atom.Но главная идея - иметь абстрактный словарь, понятный любому клиенту.Почему тогда не WADL?хорошо WADL только для открытия службы.Идея заключается в том, чтобы иметь легкий абстрактный словарный запас, который послужил бы основой для гипермедиа.«Корневой» словарь.Как и в owl, мы имеем owl: thing ... и т.д. Теперь, если клиент знает стандарт "libraryml", он может переходить по ссылкам на понятные ему вещи (после анализа свойств типа носителя и xmlns).Если нет, то просто не будет.
Когда я не могу понять, как бороться с чем-то в архитектуре REST, я склонен видеть, как мы, люди, делаем это в Интернете.В Интернете у нас есть общий язык - HTML, который позволяет разработчикам сайтов доставлять любой конкретный контент, независимо от его значения для клиента (пользователя), браузеры понимают HTML, но не «значение» его контента.Это пользователь, который понимает (специфичный для домена) контент.Если я скажу QuantumPhysics.org, мой браузер может отобразить домашнюю страницу (в конце концов, это всего лишь HTML), и я могу прочитать домашнюю страницу.Если я понимаю квантовый, то хорошо, я могу продолжить просмотр.Если я не знаю, я просто выхожу (если я не хочу изучать трудный путь :))
- В примере с RetsLibrary.com клиентское приложение похоже на меня + мой браузер
- на QuantumPhysics.org.тип носителя "application / vnd.libraryml + xml" - это квантовая физика (знания).
- http - это http в обоих примерах.
- Теперь HTML-файл QuantumPhysics.org в RestLibrary.com - это XML + маленький крошечный абстрактный словарь (корневой ресурс и ссылка, который можно заменить чем-то вроде Atom).
Так имеет ли этот подход какое-либо значение?разве нам не нужен корневой крошечный гиперсловарь, чтобы мы могли добиться успеха с гипермедиа и концепцией «исходного URI»?
edit Да, почему не RDF в качестве корневого словаря!