Создание микросервисов

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

Рассмотрим торговый сайт Amazon.com. Со временем местонахождение корзины для виртуальных покупок меняется. Меняется графическое представление, меняется ссылка. Но люди достаточно сообразительны для того, чтобы все равно распознавать эту корзину и работать с нею. Мы понимаем, что означает корзина для покупок, даже если изменяются ее конкретная форма и используемый элемент управления. Мы знаем, что при желании увидеть корзину нам нужно работать вот с этим элементом управления. Поэтому со временем веб-страницы могут постепенно изменяться. Пока эти подразумеваемые соглашения между потребителем и сайтом соблюдаются, изменениям не нужно быть разрушительными.

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

Пример4.2. Элементы управления гиперсредой, используемые для перечня произведений альбома

  Give Blood

   (1)

  

    Awesome, short, brutish, funny and loud. Must buy!

  

   (2)

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

А если нужно приобрести альбом, мы знаем, куда перейти.

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

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

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

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

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

Лично я сторонник того, чтобы в качестве средства навигации по конечным точкам API предоставить потребителям не что иное, как ссылки.