На REST: WADL или не IDL, действительно ли следующий подход является правильным?

Этот вопрос немного долог, терпите меня. В 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. Кроме того, клиент должен смочь понять этот ресурс "домашней страницы" (корень элементов, ресурс и ссылка). Это - часть, которая могла использоваться вместо WADL: Абстрактный словарь, который должен быть понятным любым клиентом. Вы могли использовать существующий стандарт как Atom, например. Но основная идея состоит в том, чтобы иметь абстрактный словарь, понятный любым клиентом. Почему не WADL затем? хорошо wadl только для сервисного исследования. Идея здесь состоит в том, чтобы иметь легкий абстрактный словарь, который служил бы основой для гиперсреды. "Корневой" словарь. Как у совы у нас есть owl:thing... и т.д. Теперь, если клиент знает "libraryml" стандарт, это может перейти по ссылкам к вещам, которые это понимает (после парсинга свойств типа среды и xmlns). В противном случае это просто не будет.

Когда я не могу понять, как иметь дело с чем-то в архитектуре REST, я склонен видеть, как мы Люди делаем это в сети. В сети у нас есть Универсальный язык, который является HTML, который позволяет инструментам для создания сайта поставить любое определенное содержание, независимо от его значения клиенту (пользователь), Браузеры понимают HTML, но не "значение" его содержания. Это - пользователь, который понимает (зависящее от домена) содержание. Если я иду, чтобы сказать, что QuantumPhysics.org, мой браузер может представить домашнюю страницу (это - просто HTML, в конце концов), и я могу прочитать домашнюю страницу. Если я понимаю квант, затем прекрасный, я могу продолжить просматривать. Если я не делаю я просто выхожу (если я не хочу изучить hardway :))

• В примере RetsLibrary.com клиентское приложение точно так же, как me+my браузер
• на QuantumPhysics.org. тип среды "application/vnd.libraryml+xml" является квантовой физикой (знание).
• http является http в обоих примерах.
• Теперь HTML QuantumPhysics.org находится в RestLibrary.com, XML +, что крошечный небольшой абстрактный словарь (корневой ресурс и ссылка, которую Вы могли заменить чем-то как Atom).

Этот подход имеет какое-либо значение? разве нам не нужен корневой крошечный гиперсловарь, таким образом, мы можем следовать с гиперсредой и "начальным URI" за понятием?

отредактируйте Да почему не RDF как корневой словарь!