Является ли семантика данных неотъемлемой частью REST?

Question

Это продолжение вопроса, задающего объяснение ОТДЫХА.

Как вы можете видеть из комментариев к моему ответу, у нас был небольшой спор с Даррел Миллер о лучшем представлении ресурсов в средствах массовой информации.У нас было дальнейшее обсуждение по электронной почте, результатом которого стал этот вопрос.

Основное различие между нашим с Даррелом пониманием REST заключается в том, является ли семантика данных частью REST API.

Даррел считает (моя интерпретация его слов :-)), что семантика данных является неотъемлемой частью REST API, и поэтому выбранное медиа-представление должно отражать это.Таким образом, правильный REST API должен выбирать либо:

• хорошо известный носитель, такой как ATOM, для представления данных, чтобы как можно больше клиентов могли изначально понимать семантику ресурса;
• тип носителя для конкретного приложения, такой как application/vdn.mycomany.mymedia, и ожидайте, что клиент поймет этот тип носителя, чтобы иметь возможность использовать данные ресурсов.Application / xml не является хорошим представлением ресурса, поскольку он не представляет семантику в типе носителя, но требует, чтобы клиент знал больше о семантике.

Я, с другой стороны, считаю, что REST API - это отдельный уровень от фактического представления данных.Тип носителя, предоставляемый API, - это просто контейнер для передачи данных ресурса.Фактическая семантика данных обрабатывается отдельно.Таким образом, клиент, который не понимает данные, все еще может использовать REST API.Application / xml - это действительно хорошее представление данных, поскольку оно обеспечивает тесную связь для клиентов, которые понимают схему, но при этом позволяет клиентам, которые не понимают схему, выполнять некоторую базовую обработку ресурсов.

Таким образом, вопрос:являются ли данные семантической частью REST API?Должны ли мы выбирать только те типы носителей для представления ресурсов, которые фактически также представляют семантику данных?

Я был бы признателен, если бы люди разместили в своих ответах несколько цитат, предпочтительно из самого Роя Мэна.:-)

Answer 1

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

Без типа носителя клиент понятия не имеет, сможет ли он что-либо сделать с потоком байтов.Действительно, когда клиент получает заголовки, указывающие application / xml, он не знает, что делать, кроме как получить анализатор xml.

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

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

Также основополагающим принципом http является то, что посредники должны иметь возможность обрабатывать запросы, не проверяя тело, и там также application / xml является проблематичным.

Теперь, когда вы говорите, что семантика типов мультимедиа является частью API или нет...Что представляет собой API?

С точки зрения клиента, API не существует.Существует начальное представление, которое позволяет клиенту принять решение о том, что делать дальше.Тип носителя - это действительно то место, где клиент получает информацию, необходимую для навигации по "API", и как таковой, не может быть API без представлений.

Кроме того, клиент должен обладать только тремя битами знаний:местоположение начальной загрузки, протокол HTTP и типы носителей.Первый - это всего лишь URI и не передает многого, кроме местоположения представительства, необходимого для продолжения.Второй имеет уже очень четкую семантику.Третий - это тот, где у вас есть контроль, поскольку это контракт, который вы заключили со своим клиентом.

Этот контраакт гласит, что всякий раз, когда вы хотите что-то сделать, это что-то будет иметь семантику:чтобы добавить клиента, отправьте приложение /vnd.acme.customer + xml в /customers, используя POST.

Отсюда мой ответ:проектирование архитектуры REST состоит из двух этапов:моделирование ресурсов (на концептуальном уровне) и построение типов носителей.Что-нибудь еще, и вы, скорее всего, делаете это неправильно.

Answer 2

Я не вижу необходимости быть чрезмерно педантичным в этом вопросе.Ресурс может предоставлять несколько представлений;каждый со своей собственной семантикой (и даже несколькими измерениями семантики при этом).Если одно представление не обеспечивает семантику, требуемую конкретным вариантом использования, предоставьте то, которое обеспечивает.

Таким образом, клиент, который не понимает данные, все равно может использовать REST API.

Я не уверен, что это хорошая лакмусовая бумажка для определения того, что дает или не дает достойное представление.Что хорошего в клиенте, который может использовать документ, но не понимает его достаточно хорошо, чтобы что-либо с ним делать?Наверное, я не понимаю, как "базовая обработка ресурсов" делает application / xml лучшим выбором, чем какой-то произвольный двоичный объект из единиц и 0?

С тех пор, как вы попросили рекомендации, вот статья Роя Филдинга, где он "предлагает" растровое представление графиков социальных сетей.Я, конечно, могу найти машину для отображения этих растровых изображений, но какая от этого польза, если я не понимаю, что лежит в основе графика социальной сети?Позволит ли изменение представления на application / xml наивному клиенту извлечь из него дополнительный смысл, который не содержится в растровом изображении?Неа.

Answer 3

Проверьте это набор слайдов от Марка Бейкера для более подробного объяснения того, почему application / xml не удовлетворяет ограничению "самоописания".Вы также можете прочитать ряд сообщений в его блоге, в том числе это тот, где он продолжает объяснять, почему пространство имен application / xml + не эквивалентно типам мультимедиа.