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

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

Как вы можете видеть из комментариев к моему ответу, у нас был небольшой аргумент с Darrel Miller о лучшем медиа-ресурсе ресурсов. У нас было еще одно обсуждение по электронной почте, в результате которого возник этот вопрос.

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

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

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

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

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

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

Ответ 1

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

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

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

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

Это также основополагающий факт, что посредники должны иметь возможность обрабатывать запросы без проверки тела, а также приложение /xml проблематично.

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

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

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

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

Следовательно, мой ответ: проектирование архитектуры REST опирается на два этапа: моделирование ресурсов (на концептуальном уровне) и построение медиа-типа. Все остальное, и вы, вероятно, ошибаетесь.

Ответ 2

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

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

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

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

Ответ 3

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