Пользовательские типы контента: XLink против Atom

Я пытаюсь разработать интерфейс RESTful для веб-службы, подобной файловой системе. Чтобы обеспечить гиперссылку между различными ресурсами (файлами, каталогами и т. д.), я решил использовать XLink< /а>. Однако, похоже, в XLink есть странное упущение: типы контента.

Atom предоставляет атрибут для указания типа содержимого ссылок, а также отношения связанного ресурса к текущему, как в:

<link rel="alternate" type="text/html" href="http://example.org"/>

Поскольку я создаю настраиваемый тип контента для каждого из представлений моих ресурсов, мне кажется, что это важная часть информации для включения в мои гиперссылки.

Я могу найти аналог rel в спецификации XLink (label, from и to, я угадайте?), но почему тип контента отсутствует в XLink? Предполагают ли они, что роль каким-то образом предназначена для передачи того, что клиент находит в конце ссылки? Возможно, я упустил цель XLink?


rest content-type atom-feed xlink
person ladenedge    schedule 22.08.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Похоже, xlink намеренно проигнорировал это; единственное упоминание о типах или представлениях мультимедиа связано с тем, как следует интерпретировать идентификаторы фрагментов. XLink на самом деле определяет только ссылки как между ресурсами, а не их представления.

Это означает, что если вы использовали XLink, вы должны определить свой собственный способ указания ожидаемого типа мультимедиа цели ссылки, тогда как, если вы используете ссылку Atom, вы получаете целевой тип мультимедиа, но не универсальность XLink.

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

Как пример последнего: Sun Cloud API использует список объектов JSON с атрибутами rel и href для исходящих ссылок.

person mogsie    schedule 22.08.2010
comment
В конце концов я решил, что этот недостаток XLink не стоит дополнительной гибкости расширенных ссылок и тому подобного. Вместо ссылок я остановился на Atom, так как он предоставляет все, что нам нужно, если не все, что мы хотим. Большое спасибо за ваши мысли! - person ladenedge; 23.08.2010
comment
Я не хотел предвзято относиться к вам из-за своих личных предпочтений, но я бы тоже выбрал это. Ссылки Atom хорошо понятны и имеют механизм реестра и расширения, а также множество интересных ссылок (например, для истории изменений, подкачки, архивов). - person mogsie; 23.08.2010