Зачем нам нужен пользовательский тип мультимедиа при использовании гипермедиа-ссылок?

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

Одна из проблем с application/xml заключается в том, что в нем нет стандартного определения того, как выглядит ссылка. Это

<Link rel="foo" href="/foo">

or is it

<foo href="/foo">

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

Другая проблема с application/xml заключается в том, что он не содержит семантики, кроме иерархии элементов и атрибутов. Семантика должна быть передана либо типом носителя, либо отношением ссылки. Если вы используете application/xml, вы должны использовать отношения ссылок, чтобы сообщить клиенту, как использовать этот документ.

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

Я бы посоветовал взглянуть на application/hal+xml. Это ближе всего к общему XML, но с определенной семантикой ссылок.

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

Я подозреваю, что, как Даррел Миллер упомянул, цель должна состоять в том, чтобы избежать создания слишком конкретных типов - в конце концов, это было сказано:

REST API никогда не должен иметь «типизированных» ресурсов, важных для клиента.

Я чувствую, что большая часть контента в Интернете, касающегося Hypermedia в том, что касается REST, по существу нарушает этот принцип и направляет людей в неправильном направлении, потому что они вводят очень специфические «квалификаторы» (как я буду называть их) к своим ресурсам.

Вы видите такие вещи, как application/vnd.com.foo.bar+xml или application/vnd.com.example.thing+json - некоторые люди решили, что вместо использования самого типа они будут использовать параметры, например. application/xml; someKey=someValue -- это, на мой взгляд, ничем не отличается от квалификации. Для меня это типизированный ресурс.

text/html является воплощением гипертекста по той причине, что у браузера есть директива обработки, которую он использует для понимания этого типа мультимедиа. Не только рендеринг и макет, но и надежные прецеденты взаимодействия устанавливаются спецификациями HTML (например, теги привязки вызывают поиск, формы могут инициировать отправку с кодированием и т. д.), и именно по этой причине этот очень общий, очень мощный тип гипермедиа позволил всем веб-страницам, которые мы используем сегодня, появиться без какой-либо связи между вашим браузером и сервером, который их предоставляет - единственное, что необходимо, - это понимание того, что такое HTML как тип контента.

Что это означает для API? Это означает, что создание типа контента, специфичного для некоторого ресурса, определенного URI (или их набора) не использует строго гипермедиа и, вероятно, означает, что у вас есть связь между клиентом и сервером, которую REST пытается избежать. Это также означает, что application/xml и им подобные малокровны — у них есть директивы синтаксического анализа, но нет директив обработки. Хорошо спроектированный REST API будет иметь гораздо более общий тип гипермедиа, созданный не для конкретного ресурса, а скорее для четкого определения директив обработки, которые потенциальные клиенты должны понимать, чтобы участвовать.

Интересно и, по общему признанию, вероятно, спорно, то, что в text/html уже много чего есть - почему бы не использовать это? Тот факт, что наши потребители API хотят чего-то другого, кроме HTML (например, они думают, что форматы JSON или XML являются панацеей), на самом деле происходит из-за врожденного непонимания того, что означает иметь механизм приложения, управляемый гипермедиа, а именно, что директива обработки представление должно быть довольно общим. Конечно, вы можете сделать это с помощью XML, просто задав в своем API четкий набор элементов и их значение. Часть об использовании HTML была просто для иллюстрации.

Начинающие REST API, даже с богатым набором гиперссылок, выражающих переходы между состояниями через ресурсы, могут — и чаще всего так и происходит — не соответствовать тому расширяемому, долговечному архитектурному стилю, который на самом деле представляет собой REST.