[Эта статья была написана Джоном Уэзерилл.]
В недавнем блоге о микросервисах я обсуждал практику создания и настройки библиотек доступа, предлагая, чтобы «поставщик микросервисов отвечал за создание и поддержку клиентских библиотек, используемых для доступа к сервису».
А в статье Get Some REST на прошлой неделе я углубился в API REST Cloud Foundry.
Здесь я свяжу их вместе, используя CLI-клиент Cloud Foundry, который, хотя и не является библиотекой как таковой, является прекрасной иллюстрацией Curating Cloud Foundry API и техникой, которая также применяется непосредственно к API-интерфейсам микросервисов.
API REST Cloud Foundry: просто, но не легко
В публикации Get Some REST показаны точные вызовы, необходимые для отправки приложения в Cloud Foundry с использованием API Cloud Foundry REST. Использование этого API является гибким, мощным и относительно простым, но, как я уже говорил, он требует обработки ошибок, анализа ответов, получения идентификаторов GUID для различных объектов, архивации каталогов приложений и другой низкоуровневой работы. Подход к API прост, но не так прост, как может показаться на первый взгляд. Слишком много времени тратится на работу с сантехникой, когда вы действительно хотите просто приступить к развертыванию своих приложений.
Есть более легкий путь
Вместо всего этого, как насчет этого:
cf push
Эта простая команда вызывает клиента «cf», который заботится обо всех мельчайших деталях, описанных выше. Он обрабатывает ошибки, обрабатывает токен аутентификации, анализирует и интерпретирует ответы, создает zip-файл, запрашивает PaaS необходимую информацию, например, guid домена. И намного больше.
Все с одной командой.
управление
И в этом суть. Команда «cf» является отличным примером API-интерфейсов для «управления» или «курирования». Хотя API Cloud Foundry являются мощными и удобными, их сложно использовать, и в отсутствие команды «cf» любой, кто хочет использовать этот API, должен будет заняться написанием своей собственной утилиты доступа или библиотеки. И поддерживая это. И обучение других разработчиков об этом. И адаптировать его со временем по мере развития базового API.
Клиент «cf» предоставляет стандартизированную оболочку для различных вызовов API, необходимых для выполнения основных операций Cloud Foundry, таких как отправка приложения.
В большинстве случаев предпочтительно использовать инструмент cf для взаимодействия с Cloud Foundry, а не вызывать API-интерфейсы напрямую. Приемочные тесты Cloud Foundry или CATs делают именно это. Вместо того, чтобы вызывать низкоуровневые вызовы REST, как можно было бы ожидать, эти тесты, которые проверяют, что Cloud Foundry ведет себя самостоятельно, выбирают гораздо более простой и более понятный способ прямого переноса команды cf.
Это образец посла
Такой подход, напоминающий шаблон дизайна Ambassador .
Что делает посол? В реальной жизни посол является официальным посланником или представителем страны или государства, действующим в качестве связующего звена между этой страной и иностранным правительством. Посол понимает местные законы, языки, обычаи, как интерпретировать любые сообщения и как реагировать на события и ситуации, которые могут произойти. Если туристу нужна помощь, гораздо эффективнее пройти через посла, чем заниматься самими сложностями.
Точно так же команда cf действует как посланник Cloud Foundry (в частности, его REST API), так как она понимает, как с ним взаимодействовать, реагировать на исключительные условия, интерпретировать ответы и следовать обычаям Cloud Foundry (или протоколам).
Эта аналогия может немного растянуть, но дело в том, что библиотека или инструмент заботится обо всех деталях, избавляя разработчика от необходимости беспокоиться об этом.
Другие примеры руководства Cloud Foundry
Команда «cf» — не единственная библиотека / утилита доступа, доступная для Cloud Foundry. Взгляните на клиент Java cf , позволяющий многое из того же функционала через Java.
Например, вот несколько строк Java-кода, который вызывает (встроенный) клиент Java cf для печати имени каждого пространства и организации, в которой он содержится:
for (CloudSpace space : client.getSpaces()) {
System.out.printf(" %s\t(%s)%n", space.getName(),
space.getOrganization().getName());
}
Обратите внимание, что Java-клиент несколько более низкого уровня, чем cf cli, в том смысле, что он не предоставляет ни одного вызова для продвижения приложения. Возможно, высокоуровневый API необходим для обертывания всей операции push, но, с другой стороны, возможно, нет: достаточно просто вызвать клиент CIF Cli непосредственно из Java, и, как уже говорилось выше, это предпочтительный подход.
Еще одна библиотека доступа, на которую стоит обратить внимание — это JavaScript-клиент ActiveState cloud-foundry-client-js . Это удобно, если вы хотите управлять Cloud Foundry из приложения, запущенного в браузере. Как и Java-клиент, у него пока нет возможности напрямую выдвигать приложение (приветствуются запросы извлечения!), Но он обеспечивает доступ к большинству функций Cloud Foundry напрямую из JavaScript.
Все это: клиент командной строки «cf», клиентская библиотека Java и клиент JavaScript, являются хорошими иллюстрациями управления API, обеспечивая высокоуровневую оболочку для операций низкого уровня, о которых большинству разработчиков не нужно беспокоиться ,
С открытым исходным кодом это!
Я рекомендую, если возможно, открыть исходный код вашей библиотеки доступа или утилиты. В дополнение ко многим преимуществам, предоставляемым в целом открытым исходным кодом, это позволяет потребителям API непосредственно на уровне исходного кода видеть, как должны выполняться вызовы API.
Это помогает уточнить смысл спецификации в тех случаях, когда спецификация может быть двусмысленной или расплывчатой. По сути, вы предоставляете эталонную реализацию своим потребителям, помогая понять спецификацию и избегая фрагментации и неправильной интерпретации.
Преимущества такого подхода
Stewarding API имеет ряд существенных преимуществ, в то время как отказ от этого имеет некоторые недостатки.
Простое требование потребителя / клиентов вашей службы создавать свои собственные библиотеки доступа увеличивает нагрузку на процесс принятия вашей услуги, барьер для входа, которого можно легко избежать, создав собственную библиотеку доступа или утилиту.
Кроме того, если вы не управляете своими API, вы заставляете потребителей писать свои собственные библиотеки доступа. При этом возможно, что они могут неверно истолковать вашу спецификацию, и если их библиотека приобретет популярность, другие потребители в конечном итоге будут полагаться на неверные интерпретации, и произойдет фрагментация.
В любом случае, лучше избегать библиотек и инструментов множественного доступа, циркулирующих по всему сообществу.
Резюме
Микросервисы не новы, но использование микросервисов и их осведомленность в последнее время стремительно растут. Естественно, что при всей этой подверженности многие модели и практики, связанные с микросервисами, быстро развиваются. API-интерфейсы Stewarding / curating — один из примеров такой практики, которая точно воплощает команда cf (и CLI-стек).