Программирование в стиле representational state transfer (rest) на ruby

Краткое введение в HTTP

Для лучшего понимания отдельных операций REST полезно сделать краткое введение в HTTP. Это основной протокол связи, соединяющий Web-браузеры с серверами, но он используется для передачи не только HTML, но и многих других типов данных.

HTTP ― это протокол типа «запрос-ответ», то есть клиенты делают запросы, а серверы на них отвечают. Протокол HTTP довольно удобочитаем для человека, и для его демонстрации я воспользуюсь клиентом telnet, чтобы передать запрос к Web-серверу.

Запрос из браузера

Замечу, что запрос, который я сделал вручную в , должен выглядеть как URI . Web-браузер разбивает этот URI на части (как видно в ).

В приведен HTTP-запрос и часть ответа Web-сервера. Я передал запрос с помощью клиента telnet, указав доменное имя Web-сервера и порт (порт 80, типичный для HTTP). Telnet сначала преобразует доменное имя Domain Name System в IP-адрес, а затем сообщает, что я подключен к Web-серверу. После этого я ввожу строку запроса (которая содержит метод HTTP , путь к ресурсу на Web-сервере и используемый протокол ― в данном случае HTTP версии 1.1). Далее, я ввожу набор заголовков запроса (которые могут быть довольно большими, но поскольку я набираю их вручную, я просто указываю заголовок запроса , содержащий узел и ― опционально ― порт, из которого я делаю запрос). Запрос завершается пустой строкой, что указывает Web-серверу на то, что запрос окончен. Web-сервер дает ответ, содержащий используемый протокол и код состояния (в данном случае это , что указывает на то, что запрос в порядке) и дополнительные заголовки ответа. Затем следует пустая строка и собственно ответ из 1944 символов. Это содержание ресурса ― в данном случае HTML-документ.

Листинг 1. Выполнение HTTP-транзакции с помощью telnet

$ telnet mtjones.com 80
Trying 198.145.43.103...
Connected to mtjones.com.
Escape character is '^]'.
GET /index.html HTTP/1.1Host: example.org

HTTP/1.1 200 OK
Date: Sun, 25 Mar 2012 05:33:07 GMT
Server: Apache
Last-Modified: Sat, 26 Sep 2009 20:22:36 GMT
ETag: "2c984bf-798-d3451b00"
Accept-Ranges: bytes
Content-Length: 1944
Vary: Accept-Encoding
Content-Type: text/html

<DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" ...

Этот пример иллюстрирует простую транзакцию, но фактически в HTTP реализованы несколько методов. Метод используется для извлечения ресурса из Web-сервера, причем указывает на то, что это только метаданные о ресурсе (а не фактическое содержание). Метод используется для передачи на Web-сервер новых данных, а метод ― для помещения данных в существующий ресурс на Web-сервере. Полный перечень методов HTTP приведен в .

Таблица 1. Основные методы запросов HTTP 1.1

Метод	Идемпотентный	Описание
	Да	Запрос информации о возможных способах связи
	Да	Извлекает представление URI
	Да	Извлекает метаданные URI
	Да	Создает или заменяет содержание ресурса
	Нет	Добавляет содержание в существующий ресурс
	Да	Удаляет ресурс с указанным URI

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

А теперь поднимемся выше по стеку протоколов и рассмотрим уровень REST.

Запускаем наш веб-сервис

Мы создали наш веб-сервис, пора его запустить.

Сначала кликните правой кнопкой по файлу проекта Webservice.REST и выберите опцию «Назначить автозагружаемым проектом», чтобы Visual Studio запустила этот проект при запуске всего решения:

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

После запуска должно открыться окно браузера. Перейдите по адресу http://localhost:51056/TutorialService.svc/Tutorial и в зависимости от выбранного браузера вы увидите что-то такое:

Прим. перев. В вашем случае сервис может запуститься на localhost с другим портом. Далее в статье мы будем использовать значение 51056, однако не забывайте заменять его на своё, когда будете пытаться запускать примеры.

В этом примере браузер делает GET-запрос и тем самым вызывает написанный нами метод , который возвращает список со всеми туториалами.

Примечания

1. Машнин Тимур Сергеевич. Технология Web-сервисов платформы Java. — БХВ-Петербург, 2012. — С. 115. — 560 с. — ISBN 978-5-9775-0778-3.
2. ↑
3. ↑ . Tech.groups.yahoo.com. Дата обращения 28 ноября 2013.
4. . www.ics.uci.edu. Дата обращения 1 декабря 2015.
5. (11 ноября 2009). Дата обращения 1 декабря 2015.
6. ↑ Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.
7. Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST (неопр.) / Thomas Erl. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.
8. Richardson, Leonard & Ruby, Sam (2007), , O’Reilly Media, ISBN 978-0-596-52926-0. Проверено 18 января 2011.
9. , REST Definition.
10. Н. Л. Подколодный, А. В. Семенычев, Д. А. Рассказов, В. Г. Боровский, Е. А. Ананько, Е. В. Игнатьева, Н. Н. Подколодная, О. А. Подколодная, Н. А. Колчанов Распределённая система RESTful-web-сервисов для реконструкции и анализа генных сетей. Вавиловский журнал генетики и селекции, т. 16, N 4/1, 2012

История термина

Хотя данная концепция лежит в самой основе Всемирной паутины, термин «REST» был введён Роем Филдингом (англ. Roy Fielding), одним из создателей протокола «HTTP», лишь в 2000 году. В своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures») в Калифорнийском университете в Ирвайне он подвёл теоретическую основу под способ взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей представительного состояния» («Representational State Transfer). Филдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом представительном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»).

Стиль «REST» развивался параллельно с «HTTP 1.1», разработанным в 1996—1999 годах, основываясь на существующем дизайне «HTTP 1.0», разработанном в 1996 году.

Создание Spring Boot приложения

Теперь давайте перейдем к практике и реализуем очень простой REST API для приема платежей, используя возможности Spring Boot

4.1. Создание web-проекта с использованием Maven

Создайте Maven-проект в используемой вами IDE, назвав его SpringBootRestService

Обязательно используйте версию Java 8+, поскольку Spring Boot не работает с более ранними версиями

4.2. Конфигурация pom.xml

Вторым шагом необходимо настроить Spring Boot в файле pom.xml

Все приложения Spring Boot конфигурируются от spring-boot-starter-parent, поэтому перед дальнейшим определением зависимостей, добавьте starter-parent следующим образом:

Т.к. мы создаем REST API, то необходимо в качестве зависимости использовать spring-boot-starter-web, которая неявно определяет все остальные зависимости, такие как spring-core, spring-web, spring-webmvc, servlet api, и библиотеку jackson-databind, поэтому просто добавьте в pom.xml следующее:

Теперь следующие jar-библиотеки автоматически импортируются в ваш проект:

Следующий шаг — добавляем Spring Boot плагин:

Последний шаг — сделать так, чтобы Maven генерировал исполняемый jar-файл при сборке:

Ниже приведен полный файл pom.xml:

Как видите, используя одну зависимость, мы можем создать полностью функциональное web-приложение

4.3. Создание ресурсов REST

Теперь мы собираемся создать контроллер платежей вместе с POJO-классами для запросов и ответов

Напишем класс запроса платежа:

А также класс, обрабатывающий базовый ответ, возвращаемый нашим сервисом:

А теперь создадим контроллер:

4.4. Создание основного класса приложения

Этот последний шаг заключается в создании класса конфигурации и запуска приложения. Spring Boot поддерживает новую аннотацию @SpringBootApplication, которая эквивалентна использованию @Configuration, @EnableAutoConfiguration и @ComponentScan с их атрибутами по умолчанию

Таким образом, вам просто нужно создать класс, аннотированный с помощью @SpringBootApplication, а Spring Boot включит автоматическую настройку и отсканирует ваши ресурсы в текущем пакете:

Тестируем веб-сервис

Выше мы увидели, как браузер делает GET-запрос для вызова . Давайте проверим другие сценарии.

1. GET Tutorial/TutorialId — при вызове этого RESTful API клиент должен получить , соответствующий переданному .

Для вызова просто добавьте строку «/1» в конце URL, чтобы получить http://localhost:51056/TutorialService.svc/Tutorial/1. После перехода по этой ссылке вы должны увидеть следующее:

В этот раз был вызван метод , который вернул туториал с индексом 1 — «Queues».

2. POST Tutorial/TutorialName — при вызове этого API клиент отправляет запрос на добавление переданного , который сервер должен добавить в список. В этот раз нам понадобится инструмент Fiddler, который можно бесплатно скачать с официального сайта.

Запустите Fiddler и выполните следующие действия:

1. Переключитесь на вкладку Composer. Она используется для создания запросов, которые можно отравить любому веб-приложению;
2. Установите тип запроса равным «POST», а в URL вставьте адрес сервиса, в нашем случае это http://localhost:51056/TutorialService.svc/Tutorial;
3. В окне, где уже есть строка «User-Agent: Fiddler» добавьте строку «Content-Type: application/json». Наш сервис работает только с данными в формате JSON, помните?
4. Осталось ввести данные в поле «Request Body». Наш метод для POST-запросов принимает параметр . Передавая строку , мы указываем, что хотим добавить в список значение «Trees».

Нажмите на кнопку «Execute». После этого нашему сервису будет отправлен запрос на добавление «Trees».

3. DELETE Tutorial/TutorialId — при вызове этого API клиент отправит запрос на удаление из списка , которое соответствует переданному .

Запустите Fiddler и выполните следующие действия:

1. Переключитесь на вкладку Composer;
2. Установите тип запроса равным «DELETE», а в URL вставьте адрес сервиса вместе с элемента, который хотите удалить. Если мы хотим удалить второй элемент, то адрес будет http://localhost:51056/TutorialService.svc/Tutorial/1.

Нажмите на кнопку «Execute», чтобы отправить DELETE-запрос на удаление элемента «Queues».

Если мы опять запросим список всех туториалов, мы увидим, что их стало меньше на один:

Подведём итоги

• REST используется для создания легковесных, поддерживаемых и масштабируемых веб-сервисов;
• Всё больше приложений переходят на RESTful архитектуру, что обусловлено большим количеством разнообразных устройств и перемещением многих приложений в облако;
• Основные составляющие REST — ресурсы, которые располагаются на сервере, и методы GET, POST, PUT и DELETE, которые можно использовать для работы с этими ресурсами;
• Для создания RESTful веб-сервисов можно использовать Visual Studio и .NET;
• При проверке работы сервиса с запросами вроде POST, DELETE и PUT нужно использовать сторонний инструмент Fiddler, который позволяет посылать серверу запросы таких типов.

REST API – определения дизайна. Рекомендации по проектированию

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

Ресурс	GET (чтение)	POST (создать)	PUT (обновить)	DELETE (удалить)
/cars	Возвращает список всех автомобилей	Создать новый автомобиль	Массовое обновление автомобилей (используется редко)	Удалить все автомобили (вероятно, вам не следует это реализовывать)
/cars/1955	Возвращает определенный автомобиль	Метод не разрешен (405)	Обновляет конкретный автомобиль	Удаляет определенный автомобиль

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

GET /cars/1955?avaliable=true
GET /cars/1955/has-finished

Это очень плохо для вашего приложения. Если бот поисковой системы или какой-либо веб-сканер когда-либо завладеют этим URL…

Если вы должны изменить состояние, используйте , или , как в таблице выше.

Используйте подресурсы для отношений

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

GET /users/1955/blogs

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

GET /users/1955/blogs/150

Обрабатывайте ошибки с помощью HTTP-кодов состояния

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

Неважно, есть ли у вас документация или нет

Здесь вы найдете полный список HTTP-кодов состояния сервера.

Обеспечивайте нумерацию страниц, сортировку и фильтрацию

Это, надеемся, понятно. Ваше приложение, скорее всего, будет иметь огромное хранилище информации. Неверным будет вызов эндпоинтов, который вернет все автомобили и отправит вам 100 000 автомобилей одновременно. Перегрузка вашего сервера будет сумасшедшей, и вы быстро сожжете свои ресурсы.

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

Основы безопасности API

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

Аутентификация

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

Авторизация

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

Краткое заключение

В этом уроке мы рассмотрели REST API-интерфейсы и несколько моментов, которые следует учитывать при их разработке. Мы кратко рассмотрели различные шаблоны API, немного подробнее мы остановились именно на REST API.

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

Название сервиса

Для начала необходимо выбрать имя для REST сервиса. Под именем сервиса я подразумеваю его путь в URI запросе. Например, http://my-site.by/api/rest/service/name. Для выбора имени нам нужно понимать что такое “ресурсы” в архитектуре REST.

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

В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе и т.д. Если ресурс представляет собой некоторый объект, его легко представить, используя некоторый стандартный формат, например, XML или JSON. Далее сервер может отправить данный ресурс, используя выбранный формат, а клиент сможет работать с полученным от сервера ресурсом, используя этот же формат.

Пример представления ресурса “профиль” в формате JSON:

REST не накладывает явных ограничений на формат, который должен быть использован для представления ресурсов, но есть ряд правил, которым нужно следовать при разработке формата, который будет использоваться для представления ресурса:

• Клиент и сервер должны “понимать” и иметь возможность работать с выбранным форматом.
• Ресурс можно полностью описать, используя выбранный формат независимо от сложности ресурса.
• Формат должен предусматривать возможность представления связей между ресурсами.

Пример представления ресурса “заказ” и его связи с ресурсом “профиль”:

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

Обращение к ресурсу

Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес. Каждый ресурс однозначно определяется URL. Это значит, что URL по сути является первичным ключом для единицы данных. То есть, например, вторая книга с книжной полки будет иметь вид /books/2, а 41 страница в этой книге — /books/2/pages/41. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /books/2/pages/41 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Word.

Рекомендуется при определении имени REST-сервиса использовать имена ресурсов во множественном числе. Такой подход позволяет добавлять новые REST-сервисы лишь расширяя имена уже существующих. Например, сервис /books вернёт нам список всех книг, /books/3 вернёт информацию о 3-ей книге, а сервис /books/3/pages вернёт все страницы 3-ей книги.

Для сервисов, которые выполняют какие-то специфические действия над ресурсом, есть 2 подхода для указания действия: в имени сервиса или в его параметрах. Например, /books/3/clean или /books/3?clean. Я предпочитаю первый вариант, так как обычно такие сервисы не редко используют POST методы, которые не поддерживают передачу параметров в URl, что делает сервис, на мой взгляд, не очень читабельным. Используя определение типа действия в имени сервиса, мы делаем наш сервис более расширяемым, так как он не зависит от типа HTTP метода.

Также очень не рекомендуется использовать имена, включающие в себя несколько слов и описывающие бизнес составляющую сервиса (как это рекомендуется делать при именовании java методов). Например, вместо /getAllCars лучше сделать метод /cars. Если же метод нельзя никак описать одним словом, то необходимо применять единый стиль разделителей, я обычно использую ‘-’, что является наиболее популярным подходом. Например, /cars/3/can-sold.

Свойства Архитектуры REST

• Производительность — взаимодействие компонентов системы может являться доминирующим фактором производительности и эффективности сети с точки зрения пользователя;
• Масштабируемость для обеспечения большого числа компонентов и взаимодействий компонентов.

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

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

Создание простого REST-клиента

Перед тем как взяться за REST-клиент, необходимо кое-что установить. Если у вас не установлен Ruby, установите его. Я работаю под Ubuntu и для большинства таких установок использую Advanced Packaging Tool (а для других ― менеджер пакетов Ruby).

Чтобы установить пакет Ruby, выполните:

$ sudo apt-get install ruby

Можно также установить Interactive Ruby Shell (), полезное средство экспериментирования с языком Ruby:

$ sudo apt-get install irb

Наконец, вам понадобится компонент JSON для Ruby. Следующий код демонстрирует, как получить Ruby-компоненты пользовательского интерфейса и JSON.

$ sudo apt-get install rubygems1.8
$ sudo apt-get install ruby-dev
$ sudo gem install json

Если среда готова, приступим к построению простого API REST-клиента с помощью Ruby. В было показано, как взаимодействовать с HTTP-сервером посредством Ruby и как получить простое имя из объекта JSON. Опираясь на эти знания, создадим набор классов Ruby, реализующих простой API.

Во-первых, рассмотрим два примера классов, которые взаимодействуют с REST-сервером CrunchBase. Первый ориентирован на пространство имен company; второй ― на пространство имен person

Обратите внимание, что оба они расширяют минимальный набор и легко распространяются на другие элементы данных

В представлен API для взаимодействия с пространством имен company. Этот класс расширяет метод конструктора () и четыре метода, используемые для извлечения данных из JSON-записи о компании. Принцип работы этого класса состоит в том, что пользователь создает экземпляр объекта, указывая имя компании (постоянную ссылку). В рамках конструктора в CrunchBase запрашивается запись о компании. URL создается динамически путем добавления имени компании, переданного в составе метода . Для извлечения ответа используется метод , а готовый результат (хеш-объект) загружается в переменную экземпляра ().

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

Ответ JSON от CrunchBase представлен хешем, содержащим некоторое количество ключей

Обратите внимание, что в первых трех методах мы указали ключ для возврата значения. Метод перебирает хеш, указанный ключом

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

Листинг 3. Ruby-API CrunchBase для пространства имен company (company.rb).

require 'rubygems'
require 'json'
require 'net/http'

class Crunchbase_Company

  @record = nil

  def initialize( company )

    base_url = "http://api.crunchbase.com"
    url = "#{base_url}/v/1/company/#{company}.js"

    resp = Net::HTTP.get_response(URI.parse(url))

    @record = JSON.parse(resp.body)

  end

  def founded_year
    return @record
  end

  def num_employees
    return @record
  end

  def company_type
    return @record
  end

  def people

    employees = Hash.new

    relationships = @record

    if !relationships.nil?

        relationships.each do | person |
            if person == false then
                permalink = person
                title = person
                employees = title
            end
        end

    end

    return employees

  end

end

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

Листинг 4. Ruby-API CrunchBase для пространства имен person (person.rb).

require 'rubygems'
require 'json'
require 'net/http'

class Crunchbase_Person

  @record = nil

  def initialize( person )

    base_url = "http://api.crunchbase.com"
    url = "#{base_url}/v/1/person/#{person}.js"

    resp = Net::HTTP.get_response(URI.parse(url))

    @record = JSON.parse(resp.body)

  end

  def fname
    return @record
  end

  def lname
    return @record
  end

  def companies

    firms = Array.new

    @record.each do | firm |

        firms << firm

    end

    return firms

  end

end

Эти два простых класса Ruby скрывают всю сложность взаимодействия с HTTP-сервером в классе . Сложность анализа ответа JSON полностью снимается Ruby-компонентом JSON. Теперь рассмотрим пару приложений на базе этих API для демонстрации их использования.

Особенности Spring Boot

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

2.1. Простота управления зависимостями

Чтобы ускорить процесс управления зависимостями, Spring Boot неявно упаковывает необходимые сторонние зависимости для каждого типа приложения на основе Spring и предоставляет их разработчику посредством так называемых starter-пакетов (spring-boot-starter-web, spring-boot-starter-data-jpa и т.д.)

Starter-пакеты представляют собой набор удобных дескрипторов зависимостей, которые можно включить в свое приложение. Это позволит получить универсальное решение для всех, связанных со Spring технологий, избавляя программиста от лишнего поиска примеров кода и загрузки из них требуемых дескрипторов зависимостей (пример таких дескрипторов и стартовых пакетов будет показан ниже)

Например, если вы хотите начать использовать Spring Data JPA для доступа к базе данных, просто включите в свой проект зависимость spring-boot-starter-data-jpa и все будет готово (вам не придется искать совместимые драйверы баз данных и библиотеки Hibernate)

Если вы хотите создать Spring web-приложение, просто добавьте зависимость spring-boot-starter-web, которая подтянет в проект все библиотеки, необходимые для разработки Spring MVC-приложений, таких как spring-webmvc, jackson-json, validation-api и Tomcat

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

Следовательно, при использовании Spring Boot, файл pom.xml содержит намного меньше строк, чем при использовании его в Spring-приложениях

Обратитесь к , чтобы ознакомиться со всеми Spring Boot starter-пакетами

2.2. Автоматическая конфигурация

Второй превосходной возможностью Spring Boot является автоматическая конфигурация приложения

После выбора подходящего starter-пакета, Spring Boot попытается автоматически настроить Spring-приложение на основе добавленных вами jar-зависимостей

Например, если вы добавите Spring-boot-starter-web, Spring Boot автоматически сконфигурирует такие зарегистрированные бины, как DispatcherServlet, ResourceHandlers, MessageSource

Если вы используете spring-boot-starter-jdbc, Spring Boot автоматически регистрирует бины DataSource, EntityManagerFactory, TransactionManager и считывает информацию для подключения к базе данных из файла application.properties

Если вы не собираетесь использовать базу данных, и не предоставляете никаких подробных сведений о подключении в ручном режиме, Spring Boot автоматически настроит базу в памяти, без какой-либо дополнительной конфигурации с вашей стороны (при наличии H2 или HSQL библиотек)

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

2.3. Встроенная поддержка сервера приложений — контейнера сервлетов

Каждое Spring Boot web-приложение включает встроенный web-сервер. Посмотрите на контейнеров сервлетов, которые поддерживаются «из коробки»

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

Если вам нужно использовать отдельный HTTP-сервер, для этого достаточно исключить зависимости по умолчанию. Spring Boot предоставляет отдельные starter-пакеты для разных HTTP-серверов

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

REST and HTTP are not same !!

A lot of people prefer to compare HTTP with REST. REST and HTTP are not same.

Though, because REST also intends to make the web (internet) more streamline and standard, he advocates using REST principles more strictly. And that’s from where people try to start comparing REST with web (HTTP). Roy fielding, in his dissertation, nowhere mentioned any implementation directive – including any protocol preference and HTTP. Till the time, you are honoring the 6 guiding principles of REST, you can call your interface RESTful.

In simplest words, in the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs). The resources are acted upon by using a set of simple, well-defined operations. The clients and servers exchange representations of resources by using a standardized interface and protocol – typically HTTP.

Resources are decoupled from their representation so that their content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others. Metadata about the resource is available and used, for example, to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control. And most importantly, every interaction with a resource is stateless.

All these principles help RESTful applications to be simple, lightweight, and fast.

References:

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-drivenhttp://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm