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

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

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

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

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

Ответы

Ответ 1

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

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

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

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