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

Question

Это продолжение вопроса, запрашивающего объяснение REST .

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

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

Даррел считает (моя интерпретация его слов :-)), что семантика данных является неотъемлемой частью 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 для / клиентов с помощью POST.

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

Answer 2

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

Answer 3

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

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

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

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