HATEOAS Content-Type: Пользовательский MIME-тип

Я пытался реализовать RESTFul-архитектуру, но я полностью запутался в том, хороши или плохи пользовательские медиа-типы.

В настоящее время мое приложение передает «ссылки», используя заголовок Http Link:. Это здорово, я использую его с атрибутом title, позволяя серверу описать, что на самом деле представляет собой это «действие», особенно когда оно представлено пользователю.

Где я запутался, так это в том, должен ли я указывать собственный MIME-тип или нет. Например, у меня есть концепция пользователя. Он может быть связан с текущим ресурсом. Я собираюсь привести пример и сказать, что у меня есть предмет на аукционе. У нас может быть пользователь, который «смотрит» это. Так что я бы добавил ссылку

<http://someuserrelation> rel="http://myapp/watching";title="Joe Blogg", methods="GET"

В заголовке. Если бы у вас была возможность удалить этого пользователя из просмотра, вы бы получили.

<http://someuserrelation> rel="http://myapp/watching";title="Joe Blogg", methods="GET,DELETE"

Я очень доволен этим, если у клиента есть правильная роль, он может удалить отношения. Так что я определяю, что делать с отношениями. Аккуратная вещь, скажем, мы вызываем GET для этого ресурса «отношения», я перенаправляю клиента на пользовательский ресурс.

Что меня смущает, так это то, использовать ли пользовательский тип пантомимы. В Интернете и в моей голове есть аргументы по этому поводу.

Я сделал пример, в котором я вызываю HEAD по неизвестному URL-адресу, а сервер возвращает Content-Type: application/vnd.myapp.user. Затем мой клиент решает, может ли он понять этот MIME-тип (он поддерживает сопоставление ресурсов, которые он понимает, с представлениями), и будет либо следовать ему, либо объяснять, что он не может понять, что находится в конце этой ссылки.

Это плохо?. Я должен поддерживать специальные типы пантомимы. Что особенно странно, так это то, что я более чем счастлив использовать стандартный формат application/user, но нигде не могу найти его.

Я начинаю думать, что должен пытаться полностью угадать, что будет отображаться в любом HTTP-ответе, почти до такой степени, что, возможно, мой RESTFul API должен просто отображать html вместо того, чтобы пытаться что-либо делать с json/xml.

Я пытался искать (даже в блоге Роя Филдингса), но не могу найти ничего, что описывает, как клиент должен действовать в такой ситуации.

РЕДАКТИРОВАТЬ: аргумент, который у меня есть с включением пользовательского типа, заключается в том, что это может быть не обязательно «пользователь», наблюдающий за элементом, это может быть что-то с application/vnd.myapp.group. Получив ответ, клиент знает, что в теле есть что-то другое, и поэтому переходит к представлению, отображающему группы. Но так ли плоха эта связь mime-type для просмотра?


rest hateoas
person Beau Trepp    schedule 21.01.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я бы сказал, что вы определенно хотите иметь определенный медиа-тип для всех представлений. Если вы можете найти стандартный (html, jpeg, atom и т. д.), используйте его, но если нет, вы должны определить один (или несколько).

Причина в том, что представления должны быть автономными. Это означает, что ваш клиент получает ссылку откуда-то, он должен знать, что с ней делать. Как его отобразить, как действовать дальше и т. д. Например, браузер знает, как отображать текст/html. Ваш клиент должен знать, как отображать/обрабатывать application/vnd.company.user.

Кроме того, я думаю, что у вас есть обратная сторона переговоров по содержанию. Вам не нужно вызывать HEAD, чтобы определить, какие представления поддерживает сервер. Вы можете сообщить серверу, что ваш клиент поддерживает в запросах GET/POST/etc, используя заголовок «Accepts». Действительно, это был бы стандартный способ сделать это. Затем сервер отвечает «лучшим» представлением, которое он может дать вам для ваших принятых типов пантомимы. Вам не нужно больше поездок туда и обратно.

Таким образом, хотя ссылки, которые вы предоставляете, могут содержать контекстуальную информацию, обычно задаваемую в атрибуте 'rel', например, указывает ли ссылка на "следующую страницу", "предыдущую страницу", "подписавшегося пользователя" или «владелец-пользователь» и т. д., клиент не может принимать никаких представлений по этим ссылкам. Он знает, что семантически является «пользователем», поэтому может заполнить заголовок «Accepts» всеми поддерживаемыми представлениями для пользователя (application/vnd.company.user). Если в представлении указано только text/xml, клиент ничего не может предположить ни о содержимом, ни о семантике ссылок, которые он может получить.

На практике вы, конечно, можете запрограммировать любого клиента, чтобы просто предположить, какие представления находятся под какими ссылками/URL-адресами, и вам не нужно постоянно соответствовать REST, но вы получаете много преимуществ (описано в статье Роя Филдинга) если вы это сделаете.

Еще один второстепенный момент: в ссылках не обязательно указывать, какие методы доступны для данного ресурса, для этого и нужны OPTIONS. Правда, реализуется редко.

person Robert Bräutigam    schedule 21.01.2016
comment
Видите ли, для меня странно то, что клиент и, возможно, MIME-тип почти должны указать все возможные вещи, которые могут «наблюдать». Я привел пример о том, что в будущем, возможно, будет изменен ресурс, который стоит за «наблюдением», например, на группу. Вы сказали, что клиент семантически знает, что это пользователь ... но должен ли он это делать? Разве он не должен получить MIME-тип, который сервер отправляет обратно, и обрабатывать его таким образом, вместо того, чтобы предполагать, что это application/vnd.app.user, что, если это другой ресурс, который также имеет такое отношение? - person Beau Trepp; 22.01.2016
comment
Вам не нужно указывать, что ссылка указывает на пользователя, если вы этого не хотите. Но как вы вообще узнаете, что есть ссылка? Или что означает его атрибут «отношение»? Дело в том, что любая семантика, которую вы хотите присвоить возвращаемому представлению, должна быть через MIME-тип. Так что вам как минимум нужно определить, что потенциально есть ссылки на подписчиков, а это можно сделать только через mime-тип. В противном случае сообщение не является самодостаточным. - person Robert Bräutigam; 22.01.2016

arrow_upward
0
arrow_downward

Вам не нужно отправлять HTML для обслуживания гипермедиа. Существует множество различных форматов гипермедиа, которые гораздо проще анализировать, чем HTML. https://sookocheff.com/post/api/on-choosing-a-hypermedia-format/ https://stackoverflow.com/a/13063069/607033

Вам не нужно использовать специфичный для домена тип MIME, на мой взгляд, лучше использовать словарь для домена с общим типом гипермедиа, например. микроформаты или schema.org с JSON-LD + Hydra или ATOM/XML + микроданные / RDFa и т. д. Существует множество альтернатив в зависимости от вашего вкуса. https://en.wikipedia.org/wiki/Microdata_(HTML) http://microformats.org/ http://schema.org/ http://www.hydra-cg.com/

Я не уверен, что добавление одного и того же отношения к нескольким методам является хорошим выбором. Отправка нескольких ссылок с разными заголовками ссылок с помощью d, если вы хотите: https://stackoverflow.com/a/25416118/607033

person inf3rno    schedule 07.09.2016