автордың кітабын онлайн тегін оқу Spring Boot по-быстрому
Научный редактор В. Дмитрущенков
Переводчик И. Пальти
Марк Хеклер
Spring Boot по-быстрому. — СПб.: Питер, 2022.
ISBN 978-5-4461-3942-2
© ООО Издательство "Питер", 2022
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Предисловие
Добро пожаловать
Воздушный змей взлетает против ветра, а не по ветру.
Джон Нил, эссе «Инициатива и настойчивость» (The Weekly Mirror)
На сегодняшний день написано немало книг по Spring Boot. Хороших книг, созданных хорошими специалистами. Но любой автор сам выбирает, что включать в издание, что не включать, как представить отобранный материал, и принимает множество других решений, делающих каждую книгу уникальной. То, что одному автору кажется необязательным материалом, другой считает совершенно необходимым. Мы все разработчики, и наши мнения различаются.
Мое мнение таково: в уже существующих книгах недостает кое-каких деталей, которыми, как мне кажется, либо необходимо, либо очень полезно поделиться с разработчиками, только начинающими изучать Spring Boot. Список недостающих деталей непрерывно рос по мере того, как я общался с разработчиками со всего мира, находящимися на различных этапах путешествия в мир Spring Boot. Мы все учимся разному, в разное время и по-разному. Поэтому я и решил написать данную книгу.
Если вы новичок в Spring Boot или чувствуете, что нелишним будет углубить свои знания, — и, будем откровенны, когда это было лишним? — то эта книга специально для вас. В ней охватываются ключевые возможности Spring Boot, а также применение этих возможностей на практике.
Спасибо, что присоединились ко мне в этом путешествии! Приступим!
Условные обозначения
В книге применяются следующие условные обозначения.
Курсив
Курсивом выделены новые термины.
Моноширинный шрифт
Используется для листингов программ, а также внутри абзацев для обозначения таких элементов, как функции, базы данных, типы данных, переменные среды, операторы и ключевые слова, имена файлов и их расширения, команды и параметры командной строки.
Моноширинный жирный шрифт
Показывает команды или другой текст, который пользователь должен ввести самостоятельно.
Моноширинный курсив
Показывает текст, который должен быть заменен значениями, введенными пользователем, или значениями, определяемыми контекстом.
Шрифт без засечек
Используется для обозначения URL, адресов электронной почты, названий меню, параметров, кнопок, каталогов.
Использование примеров кода
Дополнительные материалы (примеры кода, упражнения и т.д.) доступны для скачивания по адресу https://resources.oreilly.com/examples/0636920338727.
Относительно любых технических вопросов и проблем, возникших у вас при использовании примеров кода, пожалуйста, пишите по адресу электронной почты bookquestions@oreilly.com.
Эта книга создана, чтобы помочь вам в работе. В целом, если к ней прилагается какой-либо пример кода, можете использовать его в своих программах и документации. Обращаться к нам за разрешением нет необходимости, разве что вы копируете значительную часть кода. Например, написание программы, использующей несколько фрагментов кода из этой книги, не требует отдельного разрешения. Для продажи или распространения компакт-диска с примерами из книг O’Reilly, конечно, разрешение нужно.
Ответ на вопрос путем цитирования этой книги, в том числе примеров кода, не требует разрешения. Включение значительного количества кода примеров из нее в документацию вашего программного продукта требует разрешения.
Мы ценим, хотя и не требуем, ссылки на первоисточник. Ссылка на первоисточник включает название, автора, издательство и ISBN, например: «Хеклер М. Spring Boot по-быстрому. — СПб.: Питер, 2022, 978-5-4461-3942-2».
Благодарности
Нет предела моей благодарности всем, кто вдохновлял меня на написание этой книги и поддерживал во время работы над ней. Вы просто не представляете, как важно для меня то, что вы читали ее черновики и писали отзывы или просто тепло отозвались о ней в Twitter. Огромное вам спасибо!
Но есть несколько человек, сделавших эту книгу реальностью, а не просто оптимистическим планом по написанию.
Мой начальник, учитель и друг Таша Айзенберг (Tasha Isenberg). Таша, ты работала со мной, утрясая расписание, а когда ситуация стала совсем сложной, расчистила для меня дорогу для финишного рывка и помогла уложиться в основные сроки. Я очень благодарен за то, что у меня есть столь понимающий и энергичный заступник в VMware.
Доктор Дэвид Сайр (David Syer), основатель Spring Boot, Spring Cloud, Spring Batch, чей вклад в бесчисленные проекты Spring неоценим. Ваша проницательность была совершенно исключительной, а отзывы — невероятно содержательными, и никаких слов не хватит, чтобы выразить вам мою благодарность.
Грег Тернквист (Greg Turnquist), член команды Spring Data. Спасибо за критический взгляд и неприукрашенные отзывы: книга стала заметно лучше благодаря вашей бесценной новой точке зрения.
Мои редакторы Корбин Коллинз (Corbin Collins) и Сюзанна (Зан) Маккуэйд (Suzanne (Zan) McQuade). Ваша исключительная поддержка на всем пути от задумки книги до завершения вдохновляла меня на то, чтобы работать на пределе возможностей и как-то укладываться в, казалось бы, невозможные сроки. Я не мог желать большего.
Роб Романо (Rob Romano), Кэйтлин Геган (Caitlin Ghegan), Ким Сандовал (Kim Sandoval) и весь производственный отдел O’Reilly. Вы помогли мне завершить работу, придя на выручку в самый важный момент, на финишной прямой, буквально и фигурально выпустив эту книгу в мир.
Наконец, самое главное: моя прекрасная, любящая и чрезвычайно терпеливая жена Кэти. Сказать, что ты вдохновляешь меня и придаешь мне силы делать все, что я делаю, — величайшее преуменьшение. От всего сердца спасибо тебе за все.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Глава 1. Коротко о Spring Boot
В этой главе мы обсудим три важнейшие возможности Spring Boot и расскажем, как они повышают производительность труда разработчиков.
Три основополагающие возможности Spring Boot
Три важнейшие возможности Spring Boot, на которых основывается все прочее: упрощение управления зависимостями, упрощение развертывания и автоконфигурация.
Упрощение управления зависимостями с помощью стартовых пакетов
Один из самых потрясающих аспектов Spring Boot — управление зависимостями — становится действительно... управляемым.
Если вы более или менее давно разрабатываете важное программное обеспечение, то почти наверняка сталкивались с несколькими проблемами, связанными с управлением зависимостями. Любая функциональность приложения обычно требует нескольких зависимостей «переднего края». Например, чтобы предоставить реализующий REST веб-API, необходимо обеспечить способ открытия конечных точек для доступа по HTTP, прослушивания запросов, привязки этих конечных точек к методам/функциям обработки запросов с последующим формированием и возвращением соответствующих ответов.
Практически всегда все основные зависимости включают множество других зависимостей для реализации обещанной ими функциональности. Развивая пример с реализацией REST API, мы могли бы ожидать увидеть набор зависимостей (организованных в виде разумной, хотя и спорной структуры), включающих код для возврата ответов на запросы в конкретном формате, например JSON, XML, HTML; код для упаковки/распаковки объектов в требуемый (-е) формат (-ы); код для прослушивания и обработки запросов и возвращения ответов; код для декодирования сложных URI, применяемых при создании универсальных API; код поддержки различных протоколов связи и т.д.
Даже в этом относительно простом примере, вероятно, в файле сборки потребуется немало зависимостей. И это мы еще даже не думали, какую функциональность хотели бы включить в свое приложение, а говорили только про его внешние взаимодействия.
А теперь поговорим о версиях каждой из этих зависимостей.
Совместное использование библиотек требует определенной степени строгости, ведь зачастую одна версия конкретной зависимости может тестироваться (или вообще работать правильно) лишь с конкретной версией другой зависимости. И когда эти проблемы неизбежно возникают, то приводят к тому, что я называю лернейской гидрой зависимостей.
Как и ее тезка, лернейская гидра зависимостей может доставить немало проблем. И как и в случае с тезкой, никакой награды за поиск и искоренение программных ошибок, возникающих из-за расхождения версий, вас не ждет, только неуловимые окончательные диагнозы и часы, потраченные впустую на их поиск.
Знакомьтесь со Spring Boot и его стартовыми пакетами. Стартовые пакеты Spring Boot представляют собой спецификации (Bill of Materials, BOM), основанные на проверенном практикой предположении, что практически всегда создание конкретной функциональной возможности происходит практически одинаково.
В предыдущем примере при каждом создании API мы организовывали доступные для пользователей конечные точки, прослушивали на предмет запросов, обрабатывали запросы, отправляли и получали данные по сети посредством конкретного протокола и т.д. Этот паттерн проектирования/разработки/использования практически неизменен и представляет собой общепринятый подход, лишь с несколькими небольшими вариациями. И как и для прочих аналогичных паттернов, под рукой есть охватывающий его стартовый пакет Spring Boot.
Для получения всех этих связанных между собой элементов функциональности в одной зависимости приложения достаточно добавить один-единственный стартовый пакет, например spring-boot-starter-web. Все охватываемые им зависимости синхронизированы по версиям — протестированы на совместную работу, то есть проверено, что включенная в стартовый пакет версия библиотеки A корректно работает с включенной версией библиотеки Б… и В… и Г, и т.д. Это резко сокращает список зависимостей и упрощает жизнь разработчика, практически исключая труднообнаруживаемые конфликты версий среди зависимостей, необходимых для реализации неотъемлемых возможностей приложения.
В тех редких случаях, когда необходимо включить в приложение функциональность, предоставляемую другой версией включенной зависимости, можно просто переопределить протестированную версию.
При желании можно также исключать ненужные для конкретного приложения зависимости с учетом того же предостережения.
В целом идея стартовых пакетов Spring Boot существенно упрощает зависимости и сокращает усилия, необходимые для добавления целых их наборов в приложение, а также резко сокращает накладные расходы по их тестированию, поддержке и обновлению.
Упрощение развертывания с помощью исполняемых JAR-файлов
Давным-давно, в те времена, когда по земле бродили серверы приложений, развертывание приложений Java было непростой задачей.
Чтобы запустить в эксплуатацию приложения, скажем, с доступом к базе данных, подобно многим современным микросервисам и практически всем приложениям с монолитной архитектурой тогда и сейчас, — пришлось бы проделать следующее.
1. Установить и настроить сервер приложений.
2. Установить драйверы базы данных.
3. Создать соединение с базой данных.
4. Создать пул соединений.
5. Собрать и протестировать приложение.
6. Выполнить развертывание приложения и его обычно довольно многочисленных зависимостей на сервере приложений.
Обратите внимание, что этот список предполагает наличие администраторов, которые бы настроили машину/виртуальную машину, и что на каком-то этапе независимо от этого процесса была создана база данных.
Spring Boot перевернул большую часть этого неуклюжего процесса развертывания с ног на голову и схлопнул описанные шаги в один (может, два, если считать за шаг копирование/вставку с помощью команды cfpush отдельного файла в нужное место).
Spring Boot не первоисточник так называемых über JAR-файлов1, но он произвел в них переворот. Вместо того чтобы выделять каждый файл из JAR-файла приложения и всех JAR-файлов зависимостей с последующим объединением их в один целевой JAR-файл — этот процесс иногда называют шейдингом (shading), — разработчики Spring Boot посмотрели с совершенно новой точки зрения, задавшись вопросом: а нельзя ли создавать вложенные JAR-файлы с сохранением их желаемого и получающегося форматов?
Вложение JAR-файлов вместо их шейдинга позволяет устранить огромноеколичество потенциальных проблем, возникающих вследствие потенциальных конфликтов версий, когда JAR-файл зависимости A и JAR-файл зависимости Б используют различные версии В. Исчезают также возможные юридические проблемы, возникающие вследствие переупаковки программного обеспечения и объединения его с другим программным обеспечением под другой лицензией. Хранение всех JAR-файлов зависимостей в исходном формате явно позволяет избежать этих и других проблем.
Кроме того, при необходимости можно легко извлечь содержимое исполняемого JAR-файла Spring Boot. В некоторых случаях это может понадобиться, и далее в книге я расскажу почему. А пока просто знайте, что исполняемые JAR-файлы Spring Boot способны решить многие ваши проблемы.
Благодаря включению всех зависимостей в один JAR-файл Spring Boot, развертывание чрезвычайно упрощается. Вместо сбора и проверки всех развертываемых зависимостей плагин Spring Boot обеспечивает их упаковку в выходной JAR-файл. А при его наличии можно запускать приложение везде, где доступна виртуальная машина Java (JVM), с помощью команды вида java-jar<SpringBootAppName.jar>.
Это еще не все.
Достаточно установить нужное значение одного-единственного свойства в файле сборки, чтобы плагин сборки Spring Boot сделал этот один-единственный JAR-файл полностью (само-)исполняемым. При наличии на машине JVM можно не набирать (описывать в сценарии) длинную строку java-jar<SpringBootAppName.jar>, а просто набрать команду <SpringBootAppName.jar> (конечно, заменив имя файла своим) — и дело в шляпе, все запущено и работает. Проще некуда.
Автоконфигурация
Новички в Spring Boot иногда смотрят на автоконфигурацию как на какое-то волшебство. Вероятно, автоконфигурация — величайший фактор повышения производительности работы программистов из предоставляемых Spring Boot. Я часто называю ее сверхспособностью разработчиков: Spring Boot обеспечивает невероятную производительность, учитывая мнения в популярных и повторяющихся сценариях использования.
Мнения в программном обеспечении? Чем они могут помочь?!
Если вы хоть сколько-нибудь долго работали программистом, то, без сомнения, заметили частое повторение определенных паттернов. Не точь-в-точь, конечно, но довольно близко — вероятно, в 80–90 % случаев проектирование, разработка и действия разработчика относятся к типичным сценариям использования.
Я уже упоминал эту повторяемость в программном обеспечении, именно она делает стартовые пакеты Spring Boot изумительно согласованными и удобными. Повторяемость также означает, что упомянутые действия, относящиеся к написанию кода для решения конкретной задачи, готовы к упрощению.
Возьмем для примера Spring Data — проект, связанный со Spring Boot и используемый им. Мы знаем, что для любого обращения к базе данных должно быть открыто какое-либо соединение с ней. Мы также знаем, что по выполнении приложением своих задач это соединение необходимо закрыть, чтобы избежать проблем. А в промежутке, вероятно, выполняются многочисленные обращения к базе данных посредством SQL-запросов — простых и сложных, только для чтения и с возможностью записи в базу данных, — и правильное создание этих SQL-запросов требует определенных усилий.
Теперь представьте себе, что все это можно существенно упростить. Автоматически открывать соединение при задании базы данных. Автоматически закрывать соединение по завершении работы приложения. Следовать простому и логичному соглашению по автоматическому созданию запросов, с минимальными затратами усилий разработчиком. Легкая настройка даже этого минимального кода под свои нужды, опять же в соответствии с простым соглашением, для создания упомянутых сложных SQL-запросов, заведомо согласованных и эффективных.
О подобном подходе к написанию кода иногда говорят: соглашения важнее конфигурации (convention over configuration), и если конкретное соглашение для вас внове, возможно, на первый взгляд оно покажется странноватым, но станет просто глотком свежего воздуха, если вам уже приходилось реализовывать схожую функциональность с написанием порой сотен повторяющихся, отупляющих строк кода создания/освобождения ресурсов/настройки простейших задач. Spring Boot (и большинство проектов Spring) следует мантре «соглашения важнее конфигурации», гарантируя, что если следовать простым, четким и хорошо документированным соглашениям, код конфигурации будет минимальным или вообще окажется не нужен.
Кроме того, автоконфигурация наделяет разработчика сверхспособностями благодаря тому, что команда Spring подходит к конфигурации среды, придерживаясь принципа «разработчик прежде всего». Наша производительность как разработчиков наиболее высока, когда можно сосредоточиться на решаемой задаче, а не выполнять миллион рутинных операций настройки. Как же Spring Boot добивается этого?
Возьмем для примера другой связанный со Spring Boot проект — Spring Cloud Stream. При подключении к платформе обмена сообщениями наподобие RabbitMQ или Apache Kafka разработчик обычно должен указать определенные настройки для соединения с этой платформой и ее использования — имя хоста, порт, учетные данные и т.д. Концентрация внимания на нуждах разработчиков означает наличие настроек по умолчанию (на случай, если другие не указаны), создающих подходящие условия для разработчика, работающего локально: localhost, порт по умолчанию и т.д. Все это — хорошо продуманная среда выполнения, практически на 100 % совместимая со средами разработки, хотя в производственной среде это не так. В рабочей среде может понадобиться указать конкретные значения, так как среда платформы и хостинга очень изменчива.
Использование значений по умолчанию в совместно разрабатываемых проектах позволяет также существенно сократить время, необходимое для настройки среды разработки. Это чистая выгода как для вас, так и для вашей команды.
В некоторых случаях конкретные сценарии использования относятся не к упомянутым 80–90 % типичных сценариев, а к прочим 10–20 % вполне допустимых сценариев. В этих случаях можно выборочно переопределить автоконфигурацию или даже отключить ее полностью, хотя, конечно, тогда вы утратите все сверхспособности. Для изменения некоторых решений обычно требуется всего лишь задать нужные значения одного или нескольких свойств или предоставить один или несколько компонентов, реализующих нечто, для чего в Spring Boot в обычных условиях служит автоконфигурация. Другими словами, это очень просто сделать в тех редких случаях, когда действительно нужно. Автоконфигурация — инструмент с широкими возможностями, незаметно и неустанно работающий ради упрощения жизни разработчика и невероятного повышения его производительности.
Резюме
Три важнейшие возможности Spring Boot, на которых основывается все прочее: упрощение управления зависимостями, упрощение развертывания и автоконфигурация. Их все можно настраивать под свои нужды, но делать это приходится редко. И все три делают очень многое, чтобы вы стали более производительным разработчиком. Spring Boot буквально окрыляет!
В следующей главе мы рассмотрим, какой замечательный выбор есть у приступающих к созданию приложений Spring Boot. Все варианты — отличные!
1 От нем. über — «сверх». — Примеч. пер.
От нем. über — «сверх». — Примеч. пер.
Spring Boot не первоисточник так называемых über JAR-файлов1, но он произвел в них переворот. Вместо того чтобы выделять каждый файл из JAR-файла приложения и всех JAR-файлов зависимостей с последующим объединением их в один целевой JAR-файл — этот процесс иногда называют шейдингом (shading), — разработчики Spring Boot посмотрели с совершенно новой точки зрения, задавшись вопросом: а нельзя ли создавать вложенные JAR-файлы с сохранением их желаемого и получающегося форматов?
Глава 2. Выбираем инструменты и приступаем к работе
Как вы скоро увидите, начать создавать приложения Spring Boot очень просто. Сложнее всего выбрать какие-то из возможных вариантов инструментария.
В этой главе мы рассмотрим некоторые из превосходных возможностей, доступных разработчику при создании приложений Spring Boot: системы сборки, языки программирования, наборы программных средств, редакторы кода и многое другое.
Maven или Gradle?
Исторически у разработчиков приложений Java имелось несколько вариантов утилит сборки проектов. Некоторые со временем стали непопулярными, и не без причин, и теперь сообщество разработчиков сконцентрировалось на двух: Maven и Gradle. Spring Boot поддерживает обе с одинаковым успехом.
Apache Maven
Maven — популярный и надежный вариант системы автоматизации сборки. Она существует уже довольно давно, с 2002 года, став одним из основных проектов Apache Software Foundation в 2003-м. Используемый в ней декларативный подход был и остается концептуально проще альтернативных подходов, существовавших как тогда, так и сейчас: достаточно просто создать файл pom.xml в формате XML и указать в нем нужные зависимости и плагины. В команде mvn можно указать «фазу» завершения, которая выполняет желаемую задачу, например, компиляции, удаления результатов предыдущего выполнения, упаковки, выполнения приложения и т.д.:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.4.0</version>
<relativePath/> <!-- Поиск родительского узла в репозитории -->
</parent>
<groupId>com.example</groupId>
<artifactId>demo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>demo</name>
<description>Демонстрационный проект для Spring Boot</description>
<properties>
<java.version>11</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
Maven также создает (и предполагает) определенную структуру проекта по соглашению. Обычно не стоит слишком отклоняться от этой структуры, если вы не настроены сражаться с утилитой сборки, — это занятие заведомо нерациональное. Для абсолютного большинства проектов определяемая соглашением структура Maven прекрасно подходит, так что менять ее обычно смысла не имеет. На рис. 2.1 приведено приложение Spring Boot с типичной структурой проекта Maven.
Рис. 2.1. Структура проекта Maven приложения Spring Boot
Если же в какой-то момент вам покажется, что соглашения проектов Maven и/или подход с жесткой структурой слишком вас ограничивают, существует еще один прекрасный вариант.
Gradle
Gradle — еще одна популярная утилита для сборки проектов виртуальной машины Java (JVM). Выпущенная в 2008 году, Gradle генерирует минималистичный и гибкий файл сборки build.gradle на основе предметно-ориентированного языка (Domain Specific Language, DSL). Вот пример файла сборки для приложения Spring Boot:
plugins {
id 'org.springframework.boot' version '2.4.0'
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
id 'java'
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
test {
useJUnitPlatform()
}
Gradle дает возможность разработчику выбирать в качестве DSL языки программирования Groovy и Kotlin, а также предоставляет несколько других возможностей, сокращающих время сборки проектов, в частности:
• инкрементную компиляцию классов Java;
• обход компиляции для Java (если никаких изменений в код не внесено);
• специальный демон для компиляции проекта.
Выбор между Maven и Gradle
На этой стадии вам может показаться, что никакого выбора между утилитами сборки делать не надо. Почему бы просто не остановиться на Gradle?
Более жесткий декларативный, можно даже сказать, догматичный подход Maven значительно повышает единообразие процесса сборки для различных проектов и сред. Если следовать пути Maven, проблемы практически исключены и можно сосредоточиться на коде, не возясь со сборкой.
Как у любой системы сборки, связанной с программированием/написанием сценариев, у Gradle бывают проблемы с первыми выпусками новых версий языка. Но команда создателей Gradle реагирует очень быстро и решает эти проблемы весьма оперативно, однако если вы предпочитаете (или должны) сразу работать с предварительными выпусками версий языков, учитывайте этот нюанс.
Gradle, возможно, выполняет сборку несколько быстрее, а иногда и существенно быстрее, особенно в больших проектах. Тем не менее длительность сборки аналогичных проектов Maven и Gradle на основе микросервисов вряд ли будет сильно различаться.
Для простых проектов, а также проектов с очень сложными требованиями к сборке гибкость Gradle может оказаться настоящим глотком свежего воздуха. Но дополнительная гибкость Gradle, особенно в упомянутых сложных проектах, означает и большее количество времени, потраченного на тонкую настройку, диагностику и устранение неполадок, когда все работает не так, как ожидалось. Бесплатный сыр — только в мышеловке.
Spring Boot поддерживает как Maven, так и Gradle, а если вы используете Initializr (его мы обсудим в одном из следующих разделов), проект и нужный файл сборки создаются автоматически, чтобы быстро приступить к работе. Короче говоря, попробуйте обе эти утилиты и выберите ту, что лучше подходит для вас. Spring Boot с радостью поддержит любой выбор.
Java или Kotlin
Хотя с JVM можно использовать множество разных языков, наиболее широко распространены два. Один — Java, первоначальный язык JVM, второй — относительно новый для этой сферы Kotlin. Оба — полноправные «граждане» Spring Boot.
Java
В зависимости от того, что считать официальной датой рождения проекта — общедоступный выпуск 1.0 или момент создания проекта, — Java существует уже 25 или 30 лет соответственно. Но никакого застоя нет и в помине. С сентября 2017 года цикл выпуска Java составляет 6 месяцев, в результате чего новые усовершенствованные возможности появляются чаще, чем раньше. База кода была очищена от мусора, убраны возможности, ставшие ненужными вследствие появления новых, а под влиянием сообщества разработчиков появились новые жизненно важные возможности. Java процветает, как никогда ранее.
Этот быстрый темп инноваций в сочетании с долговечностью и упором на обратную совместимость Java означает, что существует бесчисленное количество мелких фирм, занимающихся созданием и поддержкой критически важных приложений Java по всему миру. Многие из этих приложений используют Spring.
Java формирует железобетонный фундамент практически для всей базы кода Spring, а поэтому прекрасно подходит в качестве языка создания приложений Spring Boot. Чтобы изучить код Spring, Spring Boot и всех связанных проектов, достаточно посетить веб-сайт GitHub, где он размещен, и просмотреть его там или клонировать проект для просмотра офлайн. Так как на Java написано множество доступных примеров кода, проектов и руководств «Для начинающих», поддержка написания приложений Spring Boot на языке Java организована лучше, чем любого другого сочетания инструментов на рынке.
Kotlin
Kotlin — относительно новый игрок на рынке. Созданный компанией JetBrains в 2010 году и открытый для всеобщего доступа в 2011-м, Kotlin облегчает использование Java. Kotlin с самого начала был спроектирован:
• лаконичным — на этом языке можно сообщить свои намерения компилятору (а равно и себе, и прочим программистам) при помощи минимального количества кода;
• безопасным — он устраняет ошибки, связанные с null-значениями, исключая возможность их использования по умолчанию, разве что разработчик осознанно переопределит поведение, чтобы это разрешить;
• интероперабельным — язык нацелен на органичное взаимодействие со всеми существующими библиотеками для JVM, Android и браузеров;
• обладающим удобными утилитами — сборка приложений Kotlin возможна как в многочисленных интегрированных средах разработки (IDE), так и из командной строки подобно приложениям Java.
Создатели Kotlin расширяют возможности языка с большой осторожностью, но все же довольно быстро. При проектировании им не требуется в первую очередь обеспечивать совместимость написанного на языке более чем за 25 лет, поэтому они быстро добавили очень удобные возможности, которые появятся в Java лишь многие версии спустя.
Kotlin — не только лаконичный, но и очень гибкий язык. Не углубляясь в нюансы, скажем только, что обеспечить такое лингвистическое изящество помогают несколько возможностей языка, в том числе функции расширения и инфиксная нотация. Мы обсудим их подробнее чуть позже, но Kotlin допускает следующие синтаксические конструкции:
infix fun Int.multiplyBy(x: Int): Int { ... }
// вызов функции с помощью инфиксной нотации
1 multiplyBy 2
// означает то же самое, что и
1.multiplyBy(2)
Легко представить, что возможность задавать собственный, более гибкий «язык в языке» может принести немалую пользу при проектировании API. Вдобавок Kotlin лаконичен, что делает написанные на нем приложения Spring Boot еще более короткими и удобочитаемыми по сравнению с аналогами на Java, причем ясность выражения намерений в них не утрачивается.
Kotlin был полноправной частью фреймворка Spring с момента выхода осенью 2017 года версии 5.0, распространения полной поддержки на Spring Boot (весна 2018-го) и прочих проектов компонентов позднее. Кроме того, документация Spring была расширена и теперь включает примеры как на Java, так и на Kotlin. Это значит, что можно писать целые приложения Spring Boot на Kotlin так же легко, как и на Java.
Выбор между Java и Kotlin
Самое замечательное, что выбирать на самом деле не надо. Kotlin компилируется в тот же байткод, что и Java, а поскольку можно создавать проекты Spring, включающие файлы исходного кода как на Java, так и на Kotlin и с легкостью вызывать оба компилятора, то можно использовать тот из них, который удобнее даже в рамках одного проекта. Как насчет того, чтобы поймать сразу двух зайцев?
Конечно, если вы предпочитаете один из этих языков или у вас есть иные личные либо профессиональные причины, то можете разрабатывать целые приложения на том или другом. Хорошо, когда есть выбор, правда?
Выбираем версию Spring Boot
Для находящихся в продакшене приложений всегда следует использовать актуальную версию Spring Boot со следующими временными и очень узкими исключениями.
• Вы сейчас работаете с более старой версией, но обновляете, повторно тестируете и развертываете свои приложения в таком порядке, что просто еще не дошли до конкретного приложения.
• Вы сейчас работаете с более старой версией из-за найденного конфликта или программной ошибки. Вы сообщили о ней команде создателей Spring и получили инструкции ждать обновления Spring Boot или соответствующей зависимости.
• Вам нужно использовать какие-либо возможности из мгновенной (snapshot), промежуточной (milestone) или предварительной (release candidate) необщедоступной версии, и вы готовы рисковать, применяя код, который пока еще не был объявлен общедоступным, то есть готовым для продакшена.
Spring Initializr
Существует множество способов создания приложений Spring Boot, но отправная точка у большинства одна — Spring Initializr (рис. 2.2).
Рис. 2.2. Spring Initializr
Доступ к Spring Initializr, который иногда называют просто по URL, start.spring.io, можно получить из «мастеров» создания проектов большинства крупных IDE, из командной строки, но чаще всего из браузера. Последний предоставляет несколько удобных возможностей, пока что недоступных при прочих способах.
Инсталляция Java
Я предполагаю, что если вы дочитали до этого места, то уже установили на своей машине текущую версию набора инструментов разработчика Java (Java Development Kit, JDK), иногда называемого стандартной версией платформы Java (Java Platform, Standard Edition).
Подробные инструкции по его установке выходят за рамки темы данной книги, но небольшие рекомендации не помешают, правда?
Я обнаружил, что простейший способ инсталляции на машине одного или нескольких JDK и управления ими — воспользоваться SDKMAN! (https://sdkman.io). Эта система управления пакетами также упрощает установку интерфейса командной строки Spring Boot, который вы будете использовать далее в этой книге, и многих других утилит, так что это чрезвычайно полезное вспомогательное ПО. Достаточно следовать инструкциям, которые вы получите по адресу https://sdkman.io/install, чтобы настроить все нужное.
Для установки нужной версии Java необходимо только просмотреть из среды SDKMAN! доступные варианты с помощью команды sdklistjava, а затем выполнить sdkinstalljava<вставьте_сюда_нужную_версию_java>. Есть много замечательных вариантов, но я рекомендую для начала выбрать версию с долгосрочной поддержкой (Long Term Support, LTS), скомпонованную AdoptOpenJDK в один пакет с Hotspot JVM, например 11.0.7.hs-adpt.
Если вы по каким-то причинам не хотите использовать SDKMAN!, можете просто скачать и установить JDK непосредственно с сайта https://adoptopenjdk.net/. При этом у вас все будет работать, но обновляться в дальнейшем станет труднее, как и работать с несколькими JDK.
Для создания проекта Spring Boot наилучшим способом из возможных перейдите в браузере по адресу https://start.spring.io/. Здесь мы выберем несколько опций и приступим к созданию.
В начале работы со Spring Initializr необходимо выбрать систему сборки для проекта. Как уже упоминалось, есть два замечательных варианта, Maven и Gradle. Для этого примера возьмем Maven.
Далее выбираем Java в качестве языка проекта.
Как вы уже могли заметить, в Spring Initializr достаточно хорошие значения по умолчанию для представленных опций, чтобы можно было создать проект без какого-либо вмешательства пользователя. При открытии упомянутой страницы заранее были выбраны Maven и Java. А также текущая версия Spring Boot, которую необходимо выбрать как для этого проекта, так и для большинства других.
Пока что оставим значения в разделе Project Metadata неизменными, хотя в будущих проектах станем их менять.
Кроме того, пока что мы не включаем никаких зависимостей и благодаря этому можем сосредоточиться на создании проекта, ни на что не отвлекаясь.
Впрочем, перед генерацией проекта хотелось бы отметить несколько очень удобных возможностей Spring Initializr, хотя и с небольшой оговоркой.
Если хотите изучить метаданные своего проекта и подробности относительно зависимостей, основанные на выбранных опциях, перед его генерацией можете нажать кнопку Explore или открыть раздел ProjectExplorer страницы Spring Initializr с помощью горячих клавиш Ctrl+Пробел (рис. 2.3). После этого Initializr отобразит структуру проекта и файл сборки, который будет включен в сжатый (.zip) файл проекта, подготовленный для скачивания. При этом вы можете просмотреть структуру каталогов/пакета, файл свойств приложения (подробнее об этом далее) и свойства проекта и зависимостей, указываемые в файле сборки pom.xml, поскольку для этого проекта мы используем Maven.
Это быстрый и удобный способ проверки конфигурации проекта и зависимостей перед скачиванием, извлечением и загрузкой в свой IDE новенького пустого проекта.
Еще одна небольшая, но любимая многими разработчиками возможность Spring Initializr — темный режим (dark mode). Если установить переключатель DarkUI вверху страницы, как показано на рис. 2.4, сайт перейдет в темный режим и будет делать это по умолчанию при каждом заходе на страницу. Это незначительная возможность, но если вы предпочитаете работать в темном режиме, использовать Initializr вам будет намного приятнее. Вы захотите возвращаться туда снова и снова!
Рис. 2.3. Project Explorer на сайте Spring Initializr
Рис. 2.4. Spring Initializr в темном режиме!
Далее нажмите кнопку Generate для генерации, компоновки и скачивания проекта и сохраните его в выбранный каталог на локальной машине. Затем перейдите к скачанному файлу .zip и разархивируйте его, чтобы начать разрабатывать приложение.
Прямиком из командной строки
Если вы предпочитаете работать с командной строкой или хотели бы написать сценарий для создания проекта, интерфейс командной строки Spring Boot как будто создан специально для вас. У CLI Spring Boot немало замечательных возможностей, но пока что мы сосредоточимся на создании нового проекта Boot.
Установка CLI Spring Boot
Наверное, простейший способ установки CLI Spring Boot, как и JDK, утилит Kotlin и пр., — с помощью SDKMAN!. Выполните в окне терминала:
sdk list
чтобы просмотреть все доступные для установки пакеты (на рис. 2.5 показана запись для CLI Spring Boot). Далее выполните:
sdk list springboot
чтобы просмотреть доступные версии CLI Spring Boot, и установите самую свежую (текущую) версию с помощью команды:
sdk install springboot
Если идентификатор конкретной версии не указан с помощью команды sdkinstall<утилита><идентификатор_версии>, SDKMAN! обычно устанавливает последнюю рекомендуемую версию языка/утилиты, предназначенную для продакшена. Для различных поддерживаемых пакетов это означает разное: например, в случае Java будет установлена последняя версия с долгосрочной поддержкой (LTS), а не, возможно, доступная более свежая не-LTS-версия. А все потому, что каждые шести месяцев выпускается версия Java с новым номером и периодически одна из них объявляется LTS-версией. То есть может существовать одна или несколько более новых версий, официально поддерживаемых на протяжении только шесть месяцев каждая (для оценки функциональных возможностей, тестирования и даже развертывания в продакшене), в то время как конкретный LTS-выпуск полностью поддерживается в смысле обновлений и исправления ошибок.
Это замечание в какой-то мере общее для всех. Возможны различия для разных поставщиков JDK, хотя большинство из них практически не отклоняются от общепринятого стандарта. Подробностям этого вопроса посвящены целые конференции, но для наших целей они совершенно не важны.
Рис. 2.5. CLI Spring Boot на сайте SDKMAN!
После установки CLI Spring Boot можно создать такой же проект, как мы только что создали, с помощью следующей команды:
spring init
Для разархивирования архива проекта в каталог demo можно воспользоваться командой:
unzip demo.zip -d demo
Как, неужели все так просто? Если коротко, это настройки по умолчанию. CLI Spring использует те же настройки по умолчанию, что и Spring Initializr (Maven, Java и т.д.), благодаря чему можно указывать аргументы только для значений, которые необходимо изменить. Давайте намеренно укажем значения для нескольких из этих настроек по умолчанию (а заодно добавим удобный трюк для разархивирования проекта), просто чтобы продемонстрировать, как это происходит:
spring init -a demo -l java --build maven demo
Мы по-прежнему инициализируем проект с помощью CLI Spring, но теперь указываем следующие аргументы.
• -ademo или --artifactIddemo позволяет указать идентификатор артефакта для проекта. В данном случае назовем его demo.
• -ljava или --languagejava позволяет указать основной язык проекта — Java, Kotlin или Groovy2.
• --build — флаг аргумента для системы сборки, допустимые значения — maven и gradle.
• -xdemo указывает CLI на необходимость разархивировать возвращаемый Initializr файл проекта .zip. Обратите внимание, что флаг -x указывать не обязательно, текстовая метка без расширения (как в приведенной ранее команде) трактуется как каталог для разархивирования.
При указании зависимостей ситуация несколько усложняется. Как вы могли догадаться, сложно превзойти простоту их выбора из меню, предоставляемого Spring Initializr. Но гибкость CLI Spring очень удобна для быстрого запуска, написания сценариев и построения конвейеров.
Еще один нюанс: по умолчанию CLI использует Initializr для обеспечения функциональности создания проектов, так что проекты, созданные с помощью любого из этих механизмов (CLI или веб-страницы Initializr), идентичны. Такая согласованность совершенно необходима небольшой команде, напрямую использующей возможности Spring Initializr.
Впрочем, иногда компания строго контролирует, какие зависимости могут использовать разработчики при создании проектов. Честно говоря, такой подход меня удручает и представляется очень ограниченным, мешающим компании гибко реагировать на запросы пользователей или рыночную обстановку. Из-за этого сотрудникам подобных компаний бывает сложно довести любые поставленные задачи до завершения.
В таком случае можно создать собственный генератор проектов (даже клонировать репозиторий Spring Initializr), задействуя его непосредственно через получившуюся веб-страницу, или просто открыть доступ к части REST API и использовать ее из CLI Spring. Для этого добавьте следующий параметр в приведенную ранее команду (конечно, заменив URL своим):
--target https://вставьте.тут.свой.URL.org
Работа в интегрированных средах разработки
Каким бы способом вы ни создали проект Spring Boot, для того, чтобы получить полезное приложение, вам придется открыть его и написать какой-то код.
Существуют три основные интегрированные среды разработки (IDE) и множество текстовых редакторов, вполне достойно удовлетворяющих все нужды разработчиков. В числе этих IDE (список далеко не полон!): Apache NetBeans (https://netbeans.apache.org), Eclipse (https://www.eclipse.org) и IntelliJ IDEA (https://www.jetbrains.com/idea). Все три представляют собой ПО с открытым исходным кодом (OSS), и во многих случаях их можно получить бесплатно3.
В этой книге, как и в своей повседневной деятельности, я использую в основном IntelliJ Ultimate Edition. Все варианты IDE хороши, дело скорее в личных предпочтениях (или политике либо предпочтениях компании), так что можете свободно применять все, что вам подходит и нравится. Большинство описанных приемов прекрасно переносятся между всеми основными вариантами IDE.
Существует также несколько редакторов, над которыми трудилось немало разработчиков. Некоторые, такие как Sublime Text (https://www.sublimetext.com), — платные приложения, они обрели горячих поклонников благодаря качеству и долгому сроку существования. Другие, появившиеся на рынке позднее, например Atom (https://atom.io), созданный GitHub и принадлежащий сейчас Microsoft, и Visual Studio Code (https://code.visualstudio.com) (сокращенно VSCode, создан Microsoft), быстро приобретают функциональность и верных сторонников.
В книге я иногда использую VSCode и его аналог VSCodium, собранный на основе той же базы кода, но с отключенной телеметрией/отслеживанием (https://vscodium.com). Для поддержки возможностей, которые большинство разработчиков ожидают или требуют от среды разработки, я добавил в VSCode/VSCodium следующие расширения.
• Пакет расширения Spring Boot (Pivotal) (https://oreil.ly/SBExtPack). Он включает еще несколько расширений, в том числе Spring Initializr Java Support, Spring Boot Tools и Spring Boot Dashboard, упрощающих создание и редактирование приложений Spring Boot и управление ими в VSCode соответственно.
• Отладчик для языка Java (Microsoft) (https://oreil.ly/DebuggerJava). Зависимость пакета Spring Boot Dashboard.
• Привязки клавиш IntelliJ IDEA (Keisuke Kato) (https://oreil.ly/IntellijIDEAKeys). Это расширение упрощает для меня переход между обеими IDE, поскольку в основном я использую IntelliJ.
• Поддержку языка Java (Red Hat) (https://oreil.ly/JavaLangSupport). Зависимость Spring Boot Tools.
• Maven для языка Java (Microsoft) (https://oreil.ly/MavenJava). Упрощает работу с проектами, основанными на Maven.
Существуют и другие расширения, полезные для работы с XML, Docker и прочими сопутствующими технологиями, но для наших целей необходимы лишь эти.
Вернемся к проекту Spring Boot. Далее вам нужно будет открыть его в выбранной вами IDE или текстовом редакторе. Для большинства примеров в книге будем использовать IntelliJ IDEA — созданную JetBrains IDE (написана на Java и Kotlin) с очень широкими возможностями. Если вы уже задали ассоциации своей IDE с файлами сборки проекта, дважды щелкните кнопкой мыши на файле pom.xml в корневом каталоге проекта (с помощью Finder на компьютерах Mac, проводника Windows или одного из многочисленных диспетчеров файлов в Linux) и вы автоматически загрузите проект в свою IDE. Либо откройте проект из IDE или редактора так, как рекомендуют его разработчики.
Прогулка по функции main()
Теперь, когда мы загрузили проект в IDE или в редакторе, можем взглянуть на небольшие различия проекта Spring Boot (рис. 2.6) и стандартного проекта приложения Java.
Рис. 2.6. Основной класс демонстрационного приложения Spring Boot
Стандартное приложение Java включает (по умолчанию) пустой метод publicstaticvoidmain. Выполняя приложение Java, JVM ищет этот метод в качестве начальной точки приложения, а в его отсутствие запуск приложения завершается неудачей и выдается сообщение об ошибке наподобие следующего:
Error:
Main method not found in class PlainJavaApp, please define the main method as:
public static void main(String[] args)
or a JavaFX application class must extend javafx.application.Application
Конечно, можно поместить в метод main класса Java код для выполнения, именно это приложение Spring Boot и делает. При начальной загрузке Spring Boot проверяет среду, настраивает приложение, создает начальный контекст и запускает приложение. И все это благодаря одной аннотации верхнего уровня и одной строке кода, как показано на рис. 2.7.
Рис. 2.7. Сущность приложения Spring Boot
В дальнейшем мы заглянем за кулисы этих механизмов. А пока достаточно сказать, что Boot намеренно и по умолчанию избавляет вас от многих утомительных нюансов настройки приложения во время его запуска, развязывая разработчику руки для написания осмысленного кода.
Резюме
В этой главе мы рассмотрели некоторые первоклассные варианты создания приложений Spring Boot. Предпочитаете ли вы производить сборку проектов с помощью Maven или Gradle, писать код на Java или Kotlin, создавать проекты в веб-интерфейсе Spring Initializr или его аналоге для командной строки CLI Spring Boot — все возможности и удобство Spring Boot без каких-либо компромиссов к вашим услугам. Работать с проектами Spring Boot можно также во множестве разнообразных IDE и текстовых редакторов с превосходной поддержкой Spring Boot.
Как было показано здесь и в главе 1, Spring Initializr делает все возможное для быстрого и удобного создания проектов. Spring Boot вносит значительный вклад на протяжении всего жизненного цикла разработки программного обеспечения благодаря следующим возможностям:
• упрощению управления зависимостями, играющему свою роль от создания проекта до разработки и сопровождения;
• автоконфигурации, резко сокращающей или даже исключающей шаблонный код, который в противном случае пришлось бы писать, прежде чем начать работать над проблемной областью;
• упрощению развертывания, в результате чего упаковка и развертывание становятся проще пареной репы.
И все эти возможности поддерживаются вне зависимости от выбранных вами по ходу дела системы сборки, языка программирования и набора программных средств. Удивительно гибкое и обладающее большими возможностями сочетание.
В следующей главе мы создадим свое первое приложение Spring Boot — приложение, предоставляющее REST API.
2 Spring Boot по-прежнему поддерживает Groovy, хотя он используется далеко не так широко, как Java или Kotlin.
3 Доступны два варианта: Community Edition (CE) и Ultimate Edition (UE). Community Edition поддерживает разработку приложений Java и Kotlin, но для полноценной поддержки Spring придется использовать Ultimate Edition. Определенные сценарии использования служат основанием для предоставления бесплатной лицензии на Ultimate Edition, но вы, конечно, можете приобрести ее. Кроме того, обе прекрасно поддерживают приложения Spring Boot.
Доступны два варианта: Community Edition (CE) и Ultimate Edition (UE). Community Edition поддерживает разработку приложений Java и Kotlin, но для полноценной поддержки Spring придется использовать Ultimate Edition. Определенные сценарии использования служат основанием для предоставления бесплатной лицензии на Ultimate Edition, но вы, конечно, можете приобрести ее. Кроме того, обе прекрасно поддерживают приложения Spring Boot.
Spring Boot по-прежнему поддерживает Groovy, хотя он используется далеко не так широко, как Java или Kotlin.
Существуют три основные интегрированные среды разработки (IDE) и множество текстовых редакторов, вполне достойно удовлетворяющих все нужды разработчиков. В числе этих IDE (список далеко не полон!): Apache NetBeans (https://netbeans.apache.org), Eclipse (https://www.eclipse.org) и IntelliJ IDEA (https://www.jetbrains.com/idea). Все три представляют собой ПО с открытым исходным кодом (OSS), и во многих случаях их можно получить бесплатно3.
• -ljava или --languagejava позволяет указать основной язык проекта — Java, Kotlin или Groovy2.
Глава 3. Создаем первый Spring Boot REST API
В этой главе я расскажу и покажу, как разработать простейшее работающее приложение с помощью Spring Boot. Поскольку большинство приложений предполагают доступ пользователей к серверным облачным ресурсам, обычно через пользовательский интерфейс клиентской части, программный интерфейс приложений (Application Programming Interface, API) — прекрасная отправная точка как для изучения, так и для применения на практике. Что ж, приступим.
«Как» и «почему» API
Эпоха монолитных приложений, отвечающих сразу за все, прошла.
Это не значит, что их больше нет или что их не будут создавать в дальнейшем. В силу различных обстоятельств монолитное приложение, предоставляющее «в одном флаконе» множество возможностей, все еще может пригодиться, особенно в следующих случаях:
• предметная область, а значит и ее границы, практически неизвестна;
• предоставляемые функциональные возможности тесно сцеплены, и скорость взаимодействий между модулями важнее гибкости;
• требования по масштабированию всех функциональных возможностей известны и согласованы между собой;
• функциональность стабильна, изменения происходят медленно или носят ограниченный характер, либо наблюдается и то и другое.
На все остальные случаи жизни существуют микросервисы.
Конечно, это крайне упрощенный, но полезный обзор ситуации. Благодаря разбиению функциональных возможностей на меньшие взаимосвязанные фрагменты их можно расцепить между собой, открывая дорогу для создания более гибких и надежных систем, которые удобнее сопровождать.
В любой распределенной системе — и не сомневайтесь, включающая микросервисы система относится как раз к этой категории — ключевым фактором является обмен информацией. Нет сервиса, который был бы как остров4. И хотя существуют многочисленные механизмы соединения приложений/микросервисов, чаще всего мы начинаем с эмуляции того, что пронизывает всю нашу повседневную жизнь, — интернета.
Интернет предназначен для обмена информацией. На самом деле создатели его предшественника, Сети Агентства перспективных исследовательских проектов (Advanced Research Projects Agency Network, ARPANET), предусмотрели необходимость поддержания обмена информацией между системами даже в случае серьезных сбоев. Логично предположить, что подход на основе HTTP, сходный с тем, что мы используем ежедневно, тоже позволит создавать, извлекать, обновлять и удалять различные ресурсы по сети.
И хотя я очень люблю историю, но не стану углубляться в особенности развития REST API, скажу только, что Рой Филдинг (Roy Fielding) изложил их принципы в своей диссертации 2000 года, основанной на объектной модели HTTP 1994 года.
Что такое REST и почему это важно
Как уже упоминалось, API — это спецификация/интерфейс, написанный нами, разработчиками, чтобы наш код мог использовать другой код: библиотеки, прочие приложения или сервисы. Но что означает аббревиатура REST в REST API?
REST представляет собой акроним фразы «передача состояния представления» (representational state transfer) — довольно загадочного способа заявить, что наше приложение взаимодействует с другим. Приложение A не ожидает от приложения Б сохранения своего состояния — текущего и накопленной информации о процессах — между вызовами связи. Приложение A передает представление нужной части своего состояния с каждым запросом к приложению Б. Сразу видно, почему это повышает живучесть и отказоустойчивость: состояние взаимодействий приложения Б с приложением A сохраняется в случае аварийного сбоя и перезапуска первого — приложение A может повторно выполнить запрос и продолжить с того же места, где произошел сбой.
API в стиле HTTP-глаголов
А как же REST API, иногда называемый реализующим REST (RESTful API)?
Существует несколько стандартных HTTP-команд, описанных в рабочих предложениях (request for comments, RFC) IETF (Internet Engineering Task Force, инженерный совет Интернета). Небольшое их количество постоянно применяется для создания API, периодически используются еще несколько. REST API обычно создаются на основе следующих HTTP-команд:
• POST;
• GET;
• PUT;
• PATCH;
• DELETE.
Эти команды соответствуют типовым операциям над ресурсами: созданию (POST), чтению (GET), обновлению (
