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

Question

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

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

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

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

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

Answer 1

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

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

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

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