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

Question

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

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

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

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

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

Answer 1

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

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

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

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