Создание гипермедиа-ссылок в пользовательском медиа-типе

В настоящее время я создаю набор настраиваемых типов носителей для RESTful api (например, application/vnd.mycompany.foo + xml), и я пытаюсь определить плюсы и минусы двух разных способов разоблачения гипермедийных ссылок.

Если я сначала рассмотрю, какие другие типы медиа, вероятно, лучшее место для начала, это HTML. Html позволяет мне создавать такие ссылки, как:

<image src="http://example.com/image.gif"/>
<a href="#" onclick="location.href='http://example.com/page.html'; return false;"/>
<form action="http://example.com/page.html"/>
<link rel="stylesheet" type="text/css" href="theme.css" />

Интересно, что в некоторых случаях есть определенные теги, которые имеют атрибут url, а затем есть общий тег ссылки, который использует атрибут rel для определения отношения.

В AtomPub существует также несколько способов объединения ресурсов

<collection href="#" onclick="location.href='http://example.org/blog/main'; return false;" >
         <atom:title>My Blog Entries</atom:title>
         <categories href="#" onclick="location.href='http://example.com/cats/forMain.cats'; return false;" />
</collection>

<atom:category scheme="http://example.org/extra-cats/" term="joke" />
<atom:entry>
   <link rel="edit" href="#" onclick="location.href='http://example.org/edit/first-post.atom'; return false;"/>
</atom:entry>

Вопрос, который я задаю, когда имеет смысл использовать элемент ссылки с отношением, и когда имеет смысл добавить атрибут к существующему элементу.

например. ссылки AtomPub могли быть выполнены

<collection>
      <link rel="source" href="#" onclick="location.href='http://example.org/blog/main'; return false;"/>
         <atom:title>My Blog Entries</atom:title>
         <categories>
                <link rel="source" href="#" onclick="location.href='http://example.com/cats/forMain.cats'; return false;"/>
         </categories>
</collection>

<atom:category term="joke">
     <link rel="scheme" href="#" onclick="location.href='http://example.org/extra-cats/'; return false;"/>
<atom:category>
<atom:entry edit="http://example.org/edit/first-post.atom"/>

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

Ответы

Ответ 1

Что мне понравилось в XHTML 2 было то, что каждый элемент мог есть ссылка.

Почему бы не использовать XLink, чтобы включить такую ​​же функциональность? Таким образом, не нужно выбирать.

Ответ 2

Я уверен, что семантически ваши два примера Atom эквивалентны. В спецификации Atom есть несколько мест, где ссылка без отношения считается ссылкой по умолчанию (называются ли они "я" или "источник", которые я не помню). Лично мне нравится второй пример AtomPub, потому что элементы ссылки в записи Atom (который является наиболее используемым объектом при работе с Atom в целом) определяют элементы ссылок с отношениями и используют ту же схему в категории, коллекции и рабочем пространстве элементы означают, что легче разобрать без необходимости знать множество особых условий.

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

Ответ 3

Это интересный вопрос. Один из способов взглянуть на это будет дифференцировать ссылки на "информационные" ссылки, которые ссылаются на связанные ресурсы, что клиент может (или не хочет) хотеть следовать, чтобы получить дополнительную информацию (например, элемент <categories> в atompub).

С другой стороны, это ссылки, которые "определяют" протокол, то есть "направлять" клиента через последовательность изменений состояния (например, публиковать/редактировать/удалять в случае Atompub или заказывать/просматривать/оплачивать в системе покупок) ресурса, составляющего фактический протокол (например, <link rel="edit">).

В статье Starbucks авторы раскрывают всю идею определяя (гипотетическую) схему изменений состояния. Они используют <next rel="schema url" uri="uri for next resource state"> вместо Atom <link rel="..." href="...">, но общая идея одинаков.

Конечно, можно утверждать, что после любой ссылки представляет состояние изменение для клиента. Но я думаю, что это различие имеет смысл.