Hypermedia — гипермедиа

Содержание
  1. Гипертекст и гипермедиа — 2020 — ТЕХНОЛОГИЯ
  2. Что такое гипертекст?
  3. Что такое Hypermedia?
  4. Определение
  5. Представление
  6. Технология
  7. Приложения
  8. Резюме гипертекста и гипермедиа
  9. REST with Hypermedia — Hot or Not?
  10. The REST Maturity Model
  11. Refactoring Resource URLs
  12. Changing Client Behavior without Changing Code
  13. Explorable API
  14. Client Must Understand Relations
  15. Server Must Describe Application Completely with Relations
  16. Client Must Still Have Domain Knowledge
  17. Bigger Response Payload
  18. How Should I Implement My New Shiny API?
  19. Мультимедиа и гипермедиа 2020
  20. Что такое мультимедиа?
  21. Определение мультимедиа и гипермедиа
  22. модель
  23. Резюме мультимедиа и гипермедиа
  24. Что такое гипертекст и гипермедиа: HTML-разметка и HTTP-протокол
  25. Гипермедиа
  26. Основы гипертекстовой разметки
  27. Протокол передачи гипертекста
  28. Заключение
  29. Hypermedia — то без чего ваше API не совсем REST
  30. REST или не REST?
  31. Hypermedia в сообщениях
  32. Пример переработки API «Рецепты печенек» в Hypermedia представление
  33. Hypermedia на службе перемен
  34. А как же relation?
  35. Hypermedia types или почему application/json нам не подходит
  36. Ресурсы глазами машины
  37. Vendor specific типы
  38. Hypermedia типы общего назначения

Гипертекст и гипермедиа — 2020 — ТЕХНОЛОГИЯ

Hypermedia - гипермедиа

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

Однако продвижение в технологиях и эволюция Интернета позволили программистам разработать сложные способы чтения традиционного текста, такого как гипертекст.

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

Hypermedia — это надмножество гипертекста, используемое в гораздо более широком смысле и не ограничивающееся текстовым интерфейсом. Эти два являются относительными терминами, но используются в разных контекстах, когда речь идет о мультимедийных приложениях.

Что такое гипертекст?

Hypertext — это мощный инструмент перекрестных ссылок, предназначенный для доступа пользователей к океаническому богатству взаимосвязанной информации, статической или динамической в ​​электронном формате.

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

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

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

Что такое Hypermedia?

Hypermedia — это расширение гипертекста, в котором используются несколько форм мультимедиа, таких как текстовые, графические, аудио- или видеопоследовательности, неподвижная или движущаяся графика и т. Д.

Структура гипермедиа очень похожа на структуру гипертекста, за исключением того, что она не ограничена быть просто текстовым.

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

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

Определение

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

Документы связаны друг с другом посредством гиперссылок, которые позволяют пользователям переходить от одного документа к другому на одних и тех же или разных веб-страницах.

Hypermedia, с другой стороны, является расширением термина hypertext, используемого аналогичным образом, за исключением того, что он не ограничен текстовыми элементами. На самом деле гипермедиа содержит различные медиа-элементы или морфологии, такие как аудио, изображения, видео и неподвижная или движущаяся графика.

Представление

Hypertext — это взаимосвязанная сеть документов и других средств массовой информации, на которые ссылаются ссылки. Он может содержать статический или динамический контент в электронном формате.

Статический контент — это контент, который может доставляться непосредственно конечным пользователям без каких-либо изменений, тогда как динамический контент может быть изменен на основе пользовательских входов.

Hypermedia — это следующий уровень мультимедийного опыта, который расширяет понятие гипертекстовых ссылок, включая не только текст, но и широкий спектр других мультимедийных элементов, таких как аудио, видео и графика.

Технология

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

Это облегчает эффективное использование текста и ссылок и как его реализовать во Всемирной паутине. Технология Hypermedia основана на нелинейных формах мультимедиа, которые включают не только простой текст, но и другие мультимедийные элементы для улучшения вашего общего мультимедийного опыта.

Технология Hypermedia является крупным прорывом в области образования.

Приложения

Технология Hypertext выходит за рамки обычных щелчков и доступа к ссылкам «от одного места к другому» в Интернете. Модель гипертекста может быть реализована в широком спектре приложений, а степень динамического связывания в гипертексте не ограничивается только Интернетом.

Фактически, это может быть применено к электронному изучению, литературной разведке и качественным исследованиям. Приложение Hypermedia может быть определено как сеть взаимосвязанных документов, которые связаны между собой с помощью обширных инструментов перекрестных ссылок, таких как гипертекст.

Лучшим примером гипермедиа является World Wide Web.

Резюме гипертекста и гипермедиа

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

Основное различие заключается в том, как они реализованы.

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

Идея гипермедиа — расширить функциональность мультимедийных элементов, чтобы сделать контент более интерактивным и доступным, чем раньше. Вся идея Всемирной паутины основана на концепции гипертекста и гипермедиа.

Источник: https://ru.weblogographic.com/difference-between-hypertext-and-hypermedia-7039

REST with Hypermedia — Hot or Not?

Hypermedia - гипермедиа

2018-02-10 00:00:00 +0000

Believing Roy Fielding, who first coined the REST acronym, you may callyour API a REST API only if you make use of hypertext.But what is hypermedia? This article explains what hypermedia means for creating an API, what benefits it brings and which drawbacks you might encounter when using it.

The REST Maturity Model

Before starting with Hypermedia, let’s have a look at the REST Maturity Modelconceived by Leonard Richardson:

At the bottom of the maturity pyramid we find the “Swamp of POX (Plain old XML)”. This means sending XML fragments back and forththat contain a command for executing one of several procedures as well as some payload data to a single URL. Basically, this is RPC (Remote Procedure Call) it’s done in typical SOAP webservice.

Level 1 breaks up the “single URL” part by providing separate URLs for separate “things”. These “things” are calledresources in REST-lingo. Separating concerns into different URLs is just a matter of following the software engineeringprinciple of, well, Separation of concerns.

Level 2 then builds on top of these resource URLs and provides meaningful, standardized “operations” on those resources.These operations are the HTTP Verbs, most commonly GET, POST, PUT and DELETE. This way, we have a setof verbs we can combine with a resource URL to modify the resource. Common practice is to use

  • GET to load a resource
  • POST to create a new resource
  • PUT to modify an existing resource and
  • DELETE to remove a resource.

Level 3 adds hypermedia to the mix, consisting of hyperlinks between resources, with each link representinga relation between the connected resources. The concepts behind level 3 are a little more academic thanthe other levels, and are a little harder to grasp. Read on to follow my attempt to grasp them.

I will use the term “Hypermedia” as a shorthand for “Hypermedia As The Engine Of Application State” (HATEOAS), which is one ofthe ugliest acronyms I’ve ever seen. Basically, it means that a REST API provides hyperlinks with each response thatlink to other related resources.

Let’s try this concept on a simple book store example:

In the diagram above, each node is a URL within our API and each edge is a link relating one URL with another.

Hypermedia means that those links will be returned together with the actual response payload. Let’s walk through the diagram.

Calling the root of the API (/), we will get a response that has no actual payload but a single link to /books with the relation list. This response might look this when using the HALformat:

{ «_links»: { «list»: { «href»: «/books» } }}

Following this link, we can call /books to get a list of books, which might look this:

{ «_embedded»: { «booksList»: [ { «title»: «Hitchhiker's Guide to the Galaxy», «author»: «Douglas Adams», «_links»: { «self»: { «href»: «/books/42» } } }, // more books … ] }}

The self link on each book points us to the corresponding book resource.

The book resource response then might contain a relation add linking to /cartItems, allowing us to add the book to the shopping cart.

All in all, just by following the links in the API’s responses we can browse books, add them to our shopping cart or remove them from it, andfinally order the contents of our shopping cart.

Having understood the basics of hypermedia in REST APIs, let’s discuss the pros.

The main argument for going the extra mile to level 3 and create a hypermedia-driven API is that it helps to decouple the consumer from the provider. This brings some advantages …

Refactoring Resource URLs

The consumer does not need to know all the URLs to the API’s endpoints, because it can navigate the API overthe hyperlinks provided in the responses. This gives the provider the freedom to refactor the endpoint URLs at will without consulting the consumers at all.

Changing Client Behavior without Changing Code

Another decoupling feature is that the consumer can change its behavior depending on which links are provided by theserver.

In the book store example above, the server may decide not to include the order link in its responsesuntil the shopping cart has reached a minimum value.

The client knows that and only displays a checkout buttononce it gets the order link from the server.

Explorable API

Obviously, by following the hyperlinks, our REST API is explorable by a client. However, it’s also explorable by a human. A developer that knows the root URL can simply follow the links to get a feel for the API.

Using a tool HAL Browser, the API can even be browsed andexperimented with comfortably.

While decoupling client and server is a very worthwhile goal, when implementing a hypermedia API you may stumble over a few things.

First of all, the decoupling aspect of the hyperlinks gets lost if the client chooses not to evaluate the hyperlinks but instead uses hard-coded URLs to access the API.

In this case, all the effort that has gone into crafting a semantically powerful hypermediaAPI was in vain, since the client does not take advantage of it and we loose all decouplingadvantages.

In a public-facing API, there will most probably be clients that will use hard-coded URLsand NOT evaluate the hyperlinks.So, as the API provider, we lose the advantage of hyperlinks because we still cannot refactor URLsindependently without irritating our users.

Client Must Understand Relations

If the client chooses to evaluate the hyperlinks, it obviously needs to understand the relationsto make sense of them. In the example above, the client needs to know what the remove relation meansin order to present the user with a UI that lets him remove an item from the shopping cart.

Having to understand the relations in itself is a good thing, but building a client that acts on those relationsalone is harder than building a client that is more tightly coupled to the server, which is probably a main reasonthat most APIs don’t go to level 3.

Server Must Describe Application Completely with Relations

Similarly, describing the whole application state with relations and hyperlinks is a burden on the server side — at least initially. Designing and Building a hypermedia API is plain more effort than building a level 2 API.

To be fair, once the API is stable it’s probably less effort to maintain a hypermedia API than a level 2 API, thanksto the decoupling features. But building a hypermedia API is a long-term invest few managers are willing to make.

Another reason why hypermedia is not yet widely adopted is the lack of a standard format. There’s RFC 5988, specifying a syntax for links contained in HTTP headers. Then there’sHAL, JSON Hyper-Schemaand other formats, each specifying a syntax for links within JSON resources.

Each of these formats has a different view on which information should be included in hyperlinks. This raises uncertainty amongstdevelopers and makes development of general-purpose hypermedia frameworks harder for both the client side and the server side.

Client Must Still Have Domain Knowledge

Hypermedia is not a silver bullet for decoupling client from server. The client still needs to know the structure of the resources it loads from the server and posts back to the server. This structure contains a large part of the domainknowledge, so the decoupling is far from complete.

Bigger Response Payload

As you can see in the JSON examples above, hypermedia APIs tend to have bigger response payloads than a level2 API. The links and relations need to be transferred from server to client somehow, after all. Thus, an APIimplemented with hypermedia will probably need more bandwidth than the same API without.

How Should I Implement My New Shiny API?

In my opinion, there’s no golden way of creating a REST API.

If, in your project, the advantages of hypermedia outweigh the disadvantages — mainly effort in careful design and implementation — then go for hypermedia and be one of the few who can claim to have built a glorious level 3 REST API :).

If you’re not sure, go for level 2. Especially if the client is not under your control, this may be the wiserchoice and save some implementation effort. However, be aware that you may not call your API a “REST API” then … .

Follow me on for more tips on how to become a better software developer.

Источник: https://reflectoring.io/rest-hypermedia/

Мультимедиа и гипермедиа 2020

Hypermedia - гипермедиа

Эта технология значительно изменилась благодаря традиционному использованию настольных компьютеров в конце 1950-х годов и современных современных высокотехнологичных систем.

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

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

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

Что такое мультимедиа?

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

Первоначально термин «мультимедиа» использовался в контексте мультимедийных устройств, таких как звуковые ленты, иногда дополняемые видео. Однако, поскольку технология развивается, так и цифровые медиа.

Благодаря поддержке нескольких устройств все сводится к одному интегрированному устройству, и компьютер играет центральную роль в современной мультимедийной парадигме.

Определение мультимедиа и гипермедиа

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

Проще говоря, это представление контента, использующего несколько форм мультимедиа, полное компьютерное программное обеспечение и аппаратное обеспечение.

Hypermedia, с другой стороны, представляет собой более разнообразную, нелинейную форму цифровых медиа.

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

модель

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

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

Резюме мультимедиа и гипермедиа

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

В то время как мультимедиа просто относится к нескольким формам медиа, гипермедиа используется в гораздо более широком смысле, чтобы ссылаться на СМИ со ссылками на другие медиа.Мультимедиа — это все, что вы можете видеть и слышать, тогда как гипермедиа — это то, что вы можете видеть и взаимодействовать одновременно.

Hypermedia просто означает ссылку на один тип носителя на другой тип мультимедиа с помощью интерактивных ссылок.

Источник: https://ru.esdifferent.com/difference-between-multimedia-and-hypermedia

Что такое гипертекст и гипермедиа: HTML-разметка и HTTP-протокол

Hypermedia - гипермедиа
© Holy Nothing — Bandcamp

Многие из нас слышали такой термин, как «гипертекст», однако не все знают, что именно он означает.

Изначально он появился в литературе и обозначал систему, состоящую из текстовых страниц, имеющих перекрестные ссылки.

Примерами таких текстов служат энциклопедии, словари и другие, чаще всего, научные книги, которые имеют множество сносок и ссылок, отсылающих читателя к другому фрагменту.

То есть в литературе гипертекст – это нелинейная подача информации, в отличие от стандартной, где повествование ведется последовательно (например, как в большинстве художественных произведений).

Вероятно, самый древний пример литературного гипертекста – это Библия, которая включает в себя множество книг, взаимосвязанных между собой и имеющих внутренние отсылки от одного фрагмента текста к другому.

В настоящее время «гипертекст» стал термином более компьютерным, хотя его смысл остался практически без изменения.

Гипертекст – это метод взаимосвязи одних текстов с другими при помощи гиперссылок.

Самый показательный пример гипертекста – это практически любой сайт, например, Hype.ru. Зайдите в случайный пост и там вы наткнетесь на гиперссылку внутри текста, которая ведет на другой материал. Либо опуститесь в низ статьи, и вы увидите теги, по которым можно перейти на другие страницы. Это все тот же гипертекст.

Пример гиперссылки.Идея создания устройства под названием Memex, способного работать с гипертекстом, впервые появилась в материале под названием «Как мы можем думать» Ванневара Буша, американца, советника Рузвельта.

А сам термин “гипертекст” был изобретен Тедом Нельсоном (американский социолог, философ и изобретатель) в 1962 году, а спустя 3 года в 1965 он увидел свет в очередной публикации автора.

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

Гипермедиа

© otvprim.ru

Все тот же Тед Нельсон в 1965 году ввел новый термин «гипермедиа», который означает нелинейную среду восприятия любой информации. То есть в отличие от гипертекста, гипермедиа – это совокупность текста, видео, графики, аудио и любых других видов информации, объединенных между собой гиперссылками.

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

Основы гипертекстовой разметки

HTML (HyperText Markup Language) — это язык разметки гипертекста, который представляет собой основной инструмент оформления гипертекстовых документов.

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

Как правило, теги идут попарно: сначала – так называемый открывающий, затем закрывающий тег, например,

текст документа

(данный тег позволяет разбивать текст на абзацы). Элемент, размещенный между парными тегами, называется контейнером.

Так выглядит упрощенная схема большинства HTML-документов.

© cssblok.ru

А вот так выглядит кусочек разметки главной страницы Hype.ru. Для непосвященного пользователя это все покажется абракадаброй. Впрочем, большинству пользователей понимание тегов и не требуется – структуру и значение текста распознает браузер и отображает все уже в привычном для нас виде.

Существует также XHTML (extensible hypertext markup language) — это расширяемый язык гипертекстовой разметки, который отличается строгими требованиями к оформлению гипертекстового документа.

Если в случае с HTML пользователь может допустить ошибки в разметке текста тегами, и браузер все равно правильно отобразит его, то в XHTML такое не допустимо.

XHTML практически нигде не используется, и его разработка в настоящее время прекращена.

Протокол передачи гипертекста

Каждый из нас наверняка видел, что название сайта в поисковой строке браузера начинается с аббревиатуры HTTP или HTTPS.

Они обозначают протокол передачи информации в интернете и расшифровываются, как HyperText Transfer Protocol (протокол передачи гипертекста).

HTTPS (HyperText Transfer Protocol Secure) – это тот же протокол, но подразумевающий шифрование данных, делающий передачу информации более безопасной.

Заключение

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

Источник: https://hype.tech/@id103/chto-takoe-gipertekst-i-gipermedia-html-razmetka-i-http-protokol-en71hqxn

Hypermedia — то без чего ваше API не совсем REST

Hypermedia - гипермедиа

Всем привет! Меня зовут Дмитрий Павлов, в компании Align Technology мы с коллегами занимаемся разработкой Web API для взаимодействия внутренних систем и интеграции нашей компании со сторонними вендорами. Об идеях создания API для веба, а точнее RESTful API я хотел бы рассказать в этой статье.

В последние годы тема Web API стала очень популярна, многие компании занимаются созданием подобных интерфейсов, как открытых, так и для внутреннего пользования. В описании Web API практически всегда можно встретить акроним REST, но что же это обозначает этот термин и правильно ли его используют?

REST или не REST?

Большинство разработчиков, особенно в России, понимает под REST программный интерфейс, работающий с использованием протокола HTTP[S] при условии соблюдения следующих свойств:

  • Сервер не хранит состояние клиента: никаких сессий, все что требуется для выполнения запроса клиент передаёт с самим запросом.

  • Человекочитаемые URL, в которых ресурсы идентифицируются отдельно. Никаких больше /index.php?productId=1, вместо этого используем /products/1

  • Более широкое использование HTTP методов: не ограничиваемся GET и POST, добавляем PUT и DELETE. В некоторых API можно встретить еще и PATCH.

  • В качестве формата передачи данных используется JSON.

Алгоритм по которому такой API используется обычно стандартен. Для начала нужно пойти на сайт с документацией, найти страничку со списком URL-шаблонов для доступа к ресурсам. Обычно она выглядит так:

Список ресурсов для API «Рецепты печенек» — /recipes/cookies — список рецептов печенек, GET на данный URL возвращает список доступных рецептов [ { «name» : «Овсяное печенье с шоколадом», «rating» : 5, «shortDescription» : «….» } ] POST на данный URL возволит вам создать новый рецепт. В качестве тела запроса ожидается json вида как { «name» : «Малиновое печенье», «shortDescription» : «….» …… } — /recipes/cookies/:name — рецепт печеньки с именем ${name}{ «name» : «Овсяное печенье с шоколадом», «rating» : 5, «shortDescription» : «….», «description» : «….» «ingredients» : [ { «name» : «Овсянка», ….. }, { «name» : «Масло», ….. }, { «name» : «Шоколад», ….. } ], «cookingSteps» : [ …. ]}// остальные ресурсы гипотетического API с перечсилением HTTP методов и URL шаблонов

и изучив её выполнять запросы к ресурсам (что обычно выражается в написании клиента, который по заданным форматам URL'ов подставляет параметры и обрабатывает ответы).

Примеров таких API на просторах сети предостаточно, до недавнего времени у Яндекса многие API (раз, два) заявленные как REST работали по этой схеме.

Если мы обратимся к первоисточникам, т.е.

к диссертации Роя Филдинга (на которую очень часто ссылаются, но гораздо реже читают), мы увидим, что API, созданные таким способом, не могут называться REST, поскольку они нарушают некоторые из принципов, описанных в диссертации, самый главный из которых — использование hypermedia как средства управления состоянием (Hypermedia As The Engine Of Application State ,HATEOAS), косвенно затрагивая вопросы само описываемых сообщений (self-descriptive messages).

Hypermedia в сообщениях

Суть HATEOAS состоит в подходе к описанию ресурсов нашего API.

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

Применение такого подхода обычно означает, что клиент знает некоторый конечный набор «точек входа» (можете считать их аналогами стартовых страниц на сайтах), с которых он начинает свое взаимодействие с API, используя предоставленную в представлении ресурса информацию для навигации к другим ресурсам и совершения действий.

Для достижения этой задачи как раз и используются гиперссылки (hypermedia):

  • Все ресурсы адресуемы при помощи ссылок, причем ссылки на другие ресурсы присутствуют внутри самих сообщений для их связи между собой. Клиент вместо ориентации на формат URI руководствуется идентификаторами, по которым он выбирает ссылки, располагающиеся прямо в представлении ресурса. Если ранее мы указывали в документации что нужно взять некоторый ID и на его основе построить специальный URL, тем самым делая наборы URL частью нашего API, то теперь детали формирования URL являются просто особенностями реализации сервера и клиента не волнуют. В конце концов, клиенту важно получить доступ к ресурсу, а не генерировать URL по шаблонам из документации.
  • Доступные операции над ресурсом тоже представимы в виде ссылок.

Отсутствие ссылки как на связанные ресурсы, так и на доступные действия означает, что данная операция недоступна в текущем состоянии ресурса.

Пример переработки API «Рецепты печенек» в Hypermedia представление

Возвращаясь к примеру с нашим API о каталоге рецептов печенек, преобразуем его в Hypermedia-вид.

Как вы помните, у нас был список рецептов и ресурс, подробно описывающий конкретный рецепт с перечислением ингредиентов и шагов по приготовлению. Вот как они будут выглядеть с использованием hypermedia подхода:

//список рецептов{ «links»: { «self» «/recipes/cookies» } «items»: [ { «name»: «Овсяное печенье с шоколадом», «rating»: 5, «shortDescription»: «….» «links»: { «self»: «/recipes/cookies/Овсяное печенье с шоколадом» } } ]} //конкретный рецепт{ «links»: { «self»: «/recipes/cookies/Овсяное печенье с шоколадом» } «name»: «Овсяное печенье с шоколадом», «rating»: 5, «shortDescription»: «….», «description»: «….» «ingredients»: [ { «name»: «Овсянка», ….. }, { «name»: «Масло», ….. }, { «name»: «Шоколад», ….. } ], «cookingSteps»: [ …. ]}

Значительное отличие от оригинальной версии заключается в появлении объекта links внутри каждого ресурса.

Ключи этого объекта представляют собой relation'ы (те самые идентификаторы), а значения — ссылки.

В результате наши ресурсы не требуют дополнительной информации (вне самого ресурса) о том как же перейти из каталога рецептов к детальному описанию, ссылка встроена в представление ресурса.

Данные подход позволяет легко расширять функциональность нашего API. Предположим, что мы для каждого рецепта хотим предоставить клиенту набор рекомендаций, представимый в виде списка рецептов. Сделать это очень легко, достаточно добавить в наш объект links новый ключ:

«links» : { «self» : «/recipes/cookies/Овсяное печенье с шоколадом», «http://acme.com/recipes/rels/you-can-also-» : «/recipes/cookies?related_to=Овсяное+печенье+с+шоколадом»}

Аналогично, совершенно не составит труда добавить идентификацию ингредиентов как отдельных ресурсов, если в этом возникнет необходимость.

URI не играет никакой роли, ведь теперь элементом API является relation, и мы без каких либо изменений на клиенте можем поменять ссылку на /recipes/related-to/Овсяное печенье с шоколадом или на /recipes/234892skfj45sdlkfjdsa12

Hypermedia на службе перемен

Hypermedia используется не только для навигации, но и для совершения действий, достаточно лишь определить, что некоторые relation отвечают за совершение определенных операций над ресурсами, а также обозначить семантику и детали этих операций.

Для наглядности рассмотрим пример с нашим API, добавив hypermedia-контрол для создания нового рецепта.

//список рецептов{ «links» : { «self» : «/recipes/cookies», «http://acme.com/recipes/rels/add-recipe» : «/recipes/cookies» } «items» : [ ….. ]}

Мы лишь добавили ссылку со специальным relation'ом.

Основное правило заключается в том, что клиент игнорирует неизвестные ему отношения: «старые» клиенты, не знающие как добавлять новый рецепт, будут работать как раньше, а для тех кто поддерживает создание, это будет сигналом, что есть возможность добавления нового рецепта путем отправки запроса на URI, который указан в отношении http://acme.com/recipes/rels/add-recipe.

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

Разумеется, предоставление ссылок не снимает с сервера ответсвенности за корректное оперирование HTTP методами и соблюдения их семантики :).

А как же relation?

У вас к данному моменту наверняка возник вопрос: какой смысл затевать все это, если для эффективной работы клиент все равно должен понимать смысл relation'ов? По ним-то документация должна иметься.

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

Основная идея, стоящая за заменой интерпретации URI на работу с relation'ами, состоит в большей долговечности последних.

URI является деталью реализации и может меняться со временем или от сервера к серверу. Relation же представляет собой семантическое описание связи и не завязан на детали хранения.

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

В результате появляется возможность создания более универсальных клиентов менее подверженных изменениям в случае модификаций на сервере.

Hypermedia types или почему application/json нам не подходит

Решив воспользоваться преимуществами Hypermedia подхода, мы модифицировали наш API указанным выше способом, и теперь у нас ресурсы связаны друг с другом по ссылке.

С первого взгляда может показаться, что с нашим API все в порядке, но перед тем как заявить, что у нас Hypermedia API, посмотрим на заголовок Content-Type, возвращаемый нами в ответах.

Если там стоит application/json или даже text/plain, то нам еще предстоит потрудиться.

Ресурсы глазами машины

Глядя на получившиеся у нас ресурсы, человек сразу выделяют ссылки, что создает впечатление о корректном формате нашего сообщения. Мы делаем вывод об этом, анализируя содержимое сообщения, тогда так стандарт предписывает смотреть на Content-Type заголовок ответа.

Рассмотрим следующий ответ сервера:

200 OKContent-Type: text/plain world

Нам очевидно, что в ответе содержится xml-документ, но Content-Type предписывает воспринимать содержимое как простой текст, поэтому то, что он похож на xml-документ может быть просто совпадением или частным случаем. Именно поэтому верный Content-Type так важен.

Давайте разбираться, чем же для нашей задачи не подойдет application/json? Дело в том, что стандарт, описывающий этот тип, не предусматривает никакого места или механизма для определения ссылок в нем.

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

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

Vendor specific типы

Одним из способов решить проблему корректности Content-Type'а — использовать свой собственный. В документации мы явно укажем, где у нас в сообщении расположены ссылки.

Если клиент получил от сервера ответ с нашем личным Content-Type'ом, ему не нужно будет динамически угадывать, что ссылка а что нет, если конечно он понимает наш Content-Type.

Стоит отметить, что зачастую документация с описанием типа содержит не только подробности самого формата (т.е. где расположены ссылки, а где свойства), но и другую информацию:

  • семантическое описание свойств, т.е. что они обозначают с точки зрения бизнес логики;
  • детали взаимодействия клиента с сервером, такие как HTTP методы необходимые для отправки запроса.

Такие типы называются vendor specific, поскольку часто создаются под конкретную задачу и конкретной организацией. Их нет необходимости регистрировать в IANA. Рекомендуется давать им название вида application/vnd.

${vendor}+${base_format}, где ${vendor} — это перевернутый домен компании, ${base_format} — тип который мы взяли за основу. Если компания имеет домен acme.

com и для представления наших ресурсов мы используем json, то для нашего API рецептов название типа будет выглядеть как application/vnd.com.acme.recipes+json.

Hypermedia типы общего назначения

На первый взгляд, vendor specific типы решают возникшую проблему со ссылками, но у них есть и свои проблемы:

  • типы не совместимы между собой, поэтому клиентам приходится поддерживать много разных реализаций, в случае если они взаимодействуют не с одним API, т.е. требуется поддержка отдельной библиотеки для разбора формата каждого типа, выделения в нем свойств, ссылок и прочего;
  • создание vendor specific типа под каждую задачу ведет к очень заметному росту их общего числа.

В качестве альтернативы не заставил себя ждать новый подход, который принесли типы общего назначения. Если подумать, то все что нам нужно от формата сообщений — это спецификация, отвечающая на вопросы:

  • как найти свойства наших ресурсов,
  • как найти hypermedia контролы внутри ресурса.

Именно эта задача и решается: тип общего назначения не пытается подстроиться под конкретную доменную область, ими можно описать большинство ресурсов, с которыми мы имеем дело.

Источник: https://habr.com/ru/company/aligntechnology/blog/281206/

Все термины
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: