Что такое гипермедиа, элементы управления гипермедиа, форматы гипермедиа
Я сейчас читаю книгу "Отдых на практике". Я не могу понять следующую терминологию Гипермедиа, формат гипермедиа, элементы управления гипермедиа, протокол приложения домена. Автор предполагал необходимость использования гипермедиа формата, специфичного для предметной области. Я едва мог понять это. Я погуглил эти термины, но не смог найти правильный ответ. Кто-нибудь может объяснить эти термины и почему нам нужны доменные форматы гипермедиа вместо application/xml?
2 ответа
Гипермедиа = тот факт, что клиент и сервер говорят с точки зрения некоторого унифицированного представления, например: гиперссылки.
HyperMedia Control = Ресурс должен быть обработан. Так, например, продукт представлен доменом гиперссылки /product/001, тогда ресурс может управляться (редактироваться и удаляться) с помощью домена управления гипермедиа /product/001/edit и domain/product/001/delete.
Самая большая разница в подходе. процедурные системы сначала записывают операции как переходы состояний в последовательном коде (java и т. д.), затем взаимодействия производятся в виде гиперссылок для доставки HATEOAS.
Но системы, которые рассматриваются как взаимодействия, непосредственно моделируют взаимодействия и, следовательно, доставляют гиперссылки напрямую. Пример примера: http://www.masterkube.com/hateoas_technology.html здесь.
Надеюсь это поможет.
В этом много путаницы, потому что большинство приложений, называющих себя REST, не используют гипермедиа и вовсе не REST.
Гипермедиа - это обобщение гипертекста для контента, отличного от HTML. Вы можете сказать, что гипертекст является подмножеством гипермедиа. Гипермедиа может быть HTML в браузере со всеми ссылками, кнопками и всем, что отображается, чтобы вы могли просматривать веб-сайт, или это может быть документ XML или JSON, предназначенный для анализа автоматическим клиентом, который также будет следовать ссылкам и действиям, таким как Человек будет делать с браузером, щелкая визуализированные ссылки и кнопки.
HATEOAS означает, что взаимодействие клиента с приложением REST должно управляться гипермедиа, или, проще говоря, клиент должен получать все URI для каждого ресурса, который ему необходим, следуя ссылкам в представлении самих ресурсов, а не полагаясь на внешние информация о канале, как и шаблоны URI, приведенные в документации, как это делают многие API.
Это проще, чем кажется. Это просто означает, что взаимодействие между клиентом и REST-приложением должно быть точно таким же, как человек, просматривающий веб-сайт. Возьмем для примера сам переполнение стека. Есть пользователи, вопросы и ответы. Если вы хотите просмотреть список своих вопросов, вы не заходите на веб-сайт документации, получаете шаблон URI для перечисления ваших вопросов, заполняете местозаполнитель своим идентификатором пользователя и вставляете его в свой браузер. Вы просто нажимаете на ссылку на другой документ, описанный как список вопросов, и вам даже не важно, какой именно URI. Вот что HATEOAS означает на практике.
Гипермедиа формат определяет контракт между клиентом и сервером. Это формат данных с поддержкой гиперссылок, который вы используете для конкретного представления ресурса в приложении гипермедиа. Например, если у вас есть пользовательский ресурс, вы должны задокументировать, что именно клиенты должны ожидать от представления этого ресурса, и как анализировать представление для извлечения информации. Прежде чем взаимодействовать с вашим API, ваши клиенты должны внедрить парсер для извлечения информации, они должны знать, какие свойства имеет ресурс и что они означают, какие отношения ссылок они должны ожидать и какие переходы состояний доступны и т. Д.
Элементы управления гипермедиа - это комбинации методов протокола и отношений связи в формате гипермедиа, который сообщает клиенту, какие переходы состояний доступны и как их выполнять. Например, вопрос может иметь rel=post_answer ссылка, которая ожидает представление ответа в качестве полезной нагрузки метода POST и создаст новый ресурс ответа, связанный с ним.
После того, как вы определили набор гипермедиа форматов, вам нужен специфичный для домена тип медиа, чтобы точно определить, какой гипермедиа формат используется для конкретного взаимодействия. Универсальный тип медиа типа application/xml только говорит клиенту, как анализировать формат данных, он ничего не говорит об информации, извлеченной анализатором. Например, допустим, что документ имеет медиа-тип application/vnd.mycompany.user.v1+xml клиент знает, что это версия 1.0 ресурса пользователя в формате XML. Если вы измените ресурс, добавив или удалив свойства, ссылки и т. Д., Вы можете изменить номер версии, и клиенты не сломаются, так как они могут запросить версию, для которой они были реализованы, с помощью Accept заголовок. Вы также можете предоставить несколько форматов для одного и того же ресурса, например, XML или JSON, и даже довольно удобочитаемое представление в HTML.
Когда вы объединяете все вместе - базовый протокол HTTP; контракты, определяемые форматами гипермедиа и типами мультимедиа, - у вас есть протокол приложения домена, который представляет собой весь набор ресурсов и доступных переходов состояний, объявленных вашим приложением.
Излишне говорить, что 99% так называемых REST API, которые вы найдете в Интернете, не следуют всему этому. Большинство из них - это просто API-интерфейсы HTTP, которые следуют некоторым ограничениям REST, иногда потому, что им все они не нужны, иногда потому, что разработчики думали, что REST действительно существует.