Rest и Java – обучение основам OTUS

Для того, чтобы организовать работу клиент-серверной модели, требуется научиться создавать входящие и исходящие запросы. Для этого используются разнообразные языки. Пример – SQL и MySQL.

В Java есть такое понятие как rest. Его изучению будет посвящена статья. А еще пользователи научатся посылать post-запросы для клиент-серверной модели. Информация покажется полезной тем, кто знает, что собой представляет URL и HTTP, а также умеет работать с JSON.

Определение понятия

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

Рассматриваемый стиль архитектуры – это согласованный набор ограничений для http. Он учитывается во время проектирования распределенной системы. Соответствующие ограничения носят название принципов. Их 6 штук.

Важно: утилиты, которые построены с учетом rest – это RESTful.

Как появились

REST – определение, которое было введено неким Рой Филдингом. Этот мужчина выступил в качестве одного из создателя протокола HTTP. Возникло понятие в 2000 году, поэтому можно говорить о том, что рассматриваемая особенность относительно молодая.

Концепция работы REST – основа Всемирной Паутины и HTTP протоколов. Раскрыто определение в диссертации Филдинга «Архитектурные стили и дизайн сетевых программных архитектур».

Об ограничениях и принципах

При работе с HTTP и Restful-утилитами важно помнить об ограничениях:

Определение поведения составляющих распределенных систем осуществляется через запрос-ответ.
Компонент, которые отправляет запрос – клиент, который его принимает и направляет ответ – сервер.
Запросы и ответы в основном направляются через HTTP.
Сервер – приложение, работающее в Сети. Клиентом может вступать приложение или браузер.

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

Приведение к структуре клиент-серверного характера

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

Подобное ограничение позволяет повысить переносимость клиентского кода на иные платформы. Упрощение server part идет на пользу масштабируемости. За счет существования clients и серверов подобные системы могут развиваться и работать в пределах http обособлено.

Состояние «отсутствующее»

Архитектура предусматривает соблюдение такого принципа:

В период между запросами server не должен хранить данные о состоянии клиента.

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

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

Кэширование

Еще одно ограничение – это возможность «посылающей стороны» выполнять так называемое кэширование ответов. У тех должно иметь обозначение (явное или неявное) для кэшируемых и некэшируемых сведений.

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

Единый интерфейс

Основополагающая рассматриваемой архитектуры и post запросов – это унифицированный и единообразный интерфейс:

Клиенту необходимо при любых обстоятельствах понимать, в каком виде и какие именно и куда конкретно направлять запросы.
Server обязуется разбирать то, в каком формате давать ответ.
Единый формат клиент-серверного взаимодействия описывает: что, куда, как и в каком виде отправлять.

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

О слоях

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

Кодификация по запросу

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

Почему REST

Сервис, который использует рассматриваемую архитектуру, предусматривает следующие преимущества:

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

А еще RESTful сервис легко корректируется. Для реализации поставленной задачи подойдут POST команды.

Схема client-server: как работает

Перед тем как сделать первое веб-приложение на Java, стоит разобраться в принципах работы клиент-серверной модели. Рассматриваемая архитектура позволяет отправлять на servers разнообразные команды, чтобы получать или корректировать информацию. Далее будет выдан тот или иной ответ.

Query – что и как

Клиентские queries передаются по разного рода протоколам. Почти всегда – через http. Они включают в себя:

http метод;
заголовок;
URI;
тело.

Далее каждый элемент будет рассмотрен более подробно.

Ресурсы и URI

В основе клиент-серверной модели лежит принцип манипуляции над ресурсами. Таковыми называют информацию, полученную или изменяемую clients.

Ресурс – то, чему можно присвоить какое-нибудь имя. Можно провести аналогию с классами Java. В Джаве можно создавать класс из разнообразных составляющих. В РЕСТе ситуация обстоит аналогичным образом. В качестве ресурса могут выступать:

пользователи;
отчеты;
заказы;
документация.

Соответствующие составляющие могут выступать некоторой сущностью или конкретным элементов – PDF-файлом, анимацией, видеороликом.

Client отправляет queries на эндпоинты – конечные точки (end points). Он представлен адресом в интернете. Выглядит как последовательность символов через которую идентифицируется абстрактный или физический ресурс.

Конечная точка URI – путь до ресурса. У каждого соответствующего элемента должен быть уникальный адрес. За этот момент отвечает серверный разработчик.

Http method

Метод Http – последовательность символов (исключая управляющие и разделители), которая указывает на ключевую операцию над ресурсом. Существуют различные методы. Чаще всего встречаются:

GET – получение данных о конкретном ресурсе через его ID или о коллекции оных;
PUT – корректировка через ID;
Delete – удаление ресурса посредством ID;
Post – создание нового элемента.

Это не все варианты, но у RESTful они встречаются чаще остальных.

Как быть с заголовками

Http заголовок помогает отправлять дополнительные данные об ответах или «первоначальных командах». Представлены парами ключ-значение.

Помогают слать заголовки accept на server. Требуется для того, чтобы позволить принимающей стороне разобраться, какой именно формат нужен клиенту для ответа. Разнообразные вариации форматов содержатся в неком MIME-списке типов.

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

Вот примеры MIME для файлов:

текстовый: text/plain, text/css;
картинки: image/gif;
аудио: audio/wav;
видео: video/mp4;
приложение: application/json, application/xml.

У запроса может быть заголовок типа accept: application/json. Он поможет получить ответ в JSON-формате.

Тела

Тело – сообщение, которое пересылается на сервер. Может отсутствовать. Этот момент зависит от http. Так, у get и delete нет рассматриваемого элемента. Put и post способны содержать оный. Связано это с тем, что получения информации или удаления по ID (он передается URL) нет необходимости в отправлен на server дополнительных сведений.

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

Дача ответа

Ответ включает в себя:

код;
заголовки;
тело.

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

В случае с кодами предстоит выделить несколько их групп:

1xx – информационные;
2xx – информирование об успешном принятии и обработке клиентской команды;
3xx – для успешной обработки требуется сформировать иной query, обычно – по-другому URL;
4xx – ошибка client;
5xx – ошибка server.

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

Первый проект

Для того, чтобы понять, как работает обмен информации из постов или сообщений в клиент-серверной модели через РЕСТы, стоит создать первую утилиту такого плата. Подобные services отличаются удобством и функциональностью.

Процедура будет проходить через service Spring Boot. Для реализации выбран CRUD-список операций. Действовать предстоит так:

Открыть Spring Boot.
Перейти в «Файл»-Новый»-«Проект».
Кликнуть по Spring Instializr. Далее выбрать Project SDK.
Нажать на «Далее», после чего указать тип проекта – Maven, а также указать Group и Artifact.
Продолжить работу с настройками. Здесь предстоит выбрать компоненты фреймворка. Для примера достаточно ресурсов Spring Web.
Указать имя проекта и его местоположение.
Щелкнуть по «Завершить».

На экране появится структура приложения. IDEA будет генерировать дескриптор развертывания системы сборки Maven. Это pom.xml, а также класс приложения RestExampleApplication.

О кодах

Теперь необходимо просмотреть код:

pom.xml:
<?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</ groupid artifactId >
       <version>2.2.2.RELEASE</version>
       <relativePath/> <!-- lookup parent from repository -->
   </parent>
   <groupId>com.javarush.lectures</groupId>
   <artifactId>rest_example</artifactId>
   <version>0.0.1-SNAPSHOT</version>
   <name>rest_example</name>
   <description>REST example project</description>

   <properties>
       <java.version>1.8</java.version>
   </properties>

   <dependencies>
       <dependency>
           group Id org .springframework.boot</groupId>
           <artifactId>spring-boot-starter-web</artifactId>
       </dependency>

       <dependency>
           <group Id >org.springframework.boot</groupId artifactId >spring-boot-starter-test</artifactId>
           <scope>test</scope>
           <exclusions>
               <exclusion>
                   <groupId>org.junit.vintage</group Id >
                   <artifactId>junit-vintage-engine</artifactId>
               </exclusion>
           </exclusions>
       </ dependency group id >
   </dependencies>

   <build>
       <plugins>
           <plugin>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-maven-plugin</artifactId>
           </plugin>
       </plugins>
   </build>

</project>
А у RestExampleAppication:
@SpringBootApplication
public class RestExampleApplication {

   public static void main(String[] args) {
       SpringApplication.run(RestExampleApplication.class, args);
   }

}

REST-функционал

Теперь можно создать РЕСТ-функционал, разобравшись, что собой представляют надписи groupID org, dependency groupID, а также private string и artifactid version.

Для этого потребуется:

Создать new пакет model внутри com,javarush.lectures.rest_example. Внутри «Модель» будет создан класс под названием Client.

Утилита будет работать с CRUD-операциями через ID. Поэтому далее создается сервис, реализовывающий соответствующие команды.

Теперь требуется поработать над реализацией интерфейса. Ключ – это ID Clients, значением – отправляющая request сторона. Это требуется для того, чтобы не перегружать наглядный пример спецификой функционирования БД.
В пакете service создается реализация интерфейса clientInterface.

Аннотация @Service будет говорить спрингу, что соответствующий класс – это и есть сервис. Относится к специальному типу классов, в которой реализуется бизнес-логика утилиты. Помогает получать экземпляр класса там, где это потребуется.
Нужно создать контроллер. Это спецкласс, который будет отвечать за логику обработки queries по ID на эндпоинты.
Сначала внедряется зависимость от clientservice.

Теперь пошагово каждый метод контроллера будет воплощаться в жизнь. Начать стоит с create. Для него прописывается отдельный метод.

Теперь стоит рассмотреть Read id.

Так выглядит реализация возможности получения клиента по его ID.

А вот update и delete.

Так выглядит проект с apache. Остается запустить и протестировать оный.

Запуск и тестинг

Для запуска потребуется активировать метод main в классе RequestExampleApplication. Чтобы успешно справиться с поставленной задачей, требуется загрузить программу под названием PostMan. После инициализации потребуется:

Открыть утилиту и создать query.
Щелкнуть по кнопке new в левом верхнем углу.
Выбрать Request.
Дать name оному и сохранить.
Отправить request и создать первый клиент.
Сформировать несколько подобных элементов.
Применить GET.

Теперь остается проверить, что выдаст система. На самом деле работать с post и иными командами не составляет никакого труда. А чтобы лучше разобраться в выбранном направлении, можно записаться на дистанционные специализированные образовательные курсы. В конце обучения выдается сертификат, подтверждающий знания. Пользователи смогут быстро разобраться с IT-технологиями и программированием. ID и иные понятия больше не доставят никаких хлопот.