Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-03-10

1 <ul><li><a>Определение понятия</a><ul><li><a>Как появились</a></li>

2 </ul></li>

3 <li><a>Об ограничениях и принципах</a><ul><li><a>Приведение к структуре клиент-серверного характера</a></li>

4 <li><a>Состояние "отсутствующее"</a></li>

5 <li><a>Кэширование</a></li>

6 <li><a>Единый интерфейс</a></li>

7 <li><a>О слоях</a></li>

8 <li><a>Кодификация по запросу</a></li>

9 </ul></li>

10 <li><a>Почему REST</a></li>

11 <li><a>Схема client-server: как работает</a><ul><li><a>Query - что и как</a></li>

12 <li><a>Ресурсы и URI</a></li>

13 <li><a>Http method</a></li>

14 <li><a>Как быть с заголовками</a></li>

15 <li><a>Тела</a></li>

16 </ul></li>

17 <li><a>Дача ответа</a></li>

18 <li><a>Первый проект</a><ul><li><a>О кодах</a></li>

19 <li><a>REST-функционал</a></li>

20 <li><a>Запуск и тестинг</a></li>

21 </ul></li>

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

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

24 <h2>Определение понятия</h2>

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

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

27 <p>Важно: утилиты, которые построены с учетом rest - это RESTful.</p>

28 <h3>Как появились</h3>

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

30 <p>Концепция работы REST - основа Всемирной Паутины и HTTP протоколов. Раскрыто определение в диссертации Филдинга "Архитектурные стили и дизайн сетевых программных архитектур".</p>

31 <h2>Об ограничениях и принципах</h2>

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

33 <ol><li>Определение поведения составляющих распределенных систем осуществляется через запрос-ответ.</li>

34 <li>Компонент, которые отправляет запрос - клиент, который его принимает и направляет ответ - сервер.</li>

35 <li>Запросы и ответы в основном направляются через HTTP.</li>

36 <li>Сервер - приложение, работающее в Сети. Клиентом может вступать приложение или браузер.</li>

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

38 <h3>Приведение к структуре клиент-серверного характера</h3>

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

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

41 <h3>Состояние "отсутствующее"</h3>

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

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

44 <ol><li>Обратное правило тоже действует.</li>

45 <li>Запросы клиента составляются таким образом, чтобы сервер смог извлечь из них информацию для того или иного запроса.</li>

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

47 <h3>Кэширование</h3>

48 <p>Еще одно ограничение - это возможность "посылающей стороны" выполнять так называемое кэширование ответов. У тех должно иметь обозначение (явное или неявное) для кэшируемых и некэшируемых сведений.</p>

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

50 <h3>Единый интерфейс</h3>

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

52 <ol><li>Клиенту необходимо при любых обстоятельствах понимать, в каком виде и какие именно и куда конкретно направлять запросы.</li>

53 <li>Server обязуется разбирать то, в каком формате давать ответ.</li>

54 <li>Единый формат клиент-серверного взаимодействия описывает: что, куда, как и в каком виде отправлять.</li>

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

56 <h3>О слоях</h3>

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

58 <h3>Кодификация по запросу</h3>

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

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

61 <ul><li>высокий уровень производительности (достигается за счет кэша);</li>

62 <li>масштабируемость;</li>

63 <li>наличие прозрачной системы взаимодействий;</li>

64 <li>простой и понятный интерфейс;</li>

65 <li>портативность элементов;</li>

66 <li>возможность совершенствоваться и использоваться в будущем в новых условиях/требованиях.</li>

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

68 <h2>Схема client-server: как работает</h2>

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

70 <h3>Query - что и как</h3>

71 <p>Клиентские queries передаются по разного рода протоколам. Почти всегда - через http. Они включают в себя:</p>

72 <ul><li>http метод;</li>

73 <li>заголовок;</li>

74 <li>URI;</li>

75 <li>тело.</li>

76 </ul><p>Далее каждый элемент будет рассмотрен более подробно.</p>

77 <h3>Ресурсы и URI</h3>

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

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

80 <ul><li>пользователи;</li>

81 <li>отчеты;</li>

82 <li>заказы;</li>

83 <li>документация.</li>

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

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

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

87 <h3>Http method</h3>

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

89 <ul><li>GET - получение данных о конкретном ресурсе через его ID или о коллекции оных;</li>

90 <li>PUT - корректировка через ID;</li>

91 <li>Delete - удаление ресурса посредством ID;</li>

92 <li>Post - создание нового элемента.</li>

93 </ul><p>Это не все варианты, но у RESTful они встречаются чаще остальных.</p>

94 <h3>Как быть с заголовками</h3>

95 <p>Http заголовок помогает отправлять дополнительные данные об ответах или "первоначальных командах". Представлены парами ключ-значение.</p>

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

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

98 <p>Вот примеры MIME для файлов:</p>

99 <ul><li>текстовый: text/plain, text/css;</li>

100 <li>картинки: image/gif;</li>

101 <li>аудио: audio/wav;</li>

102 <li>видео: video/mp4;</li>

103 <li>приложение: application/json, application/xml.</li>

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

105 <h3>Тела</h3>

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

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

108 <h2>Дача ответа</h2>

109 <p>Ответ включает в себя:</p>

110 <ul><li>код;</li>

111 - <li>заголовки;</li>

111 + <li>заго��овки;</li>

112 <li>тело.</li>

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

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

115 <ul><li>1xx - информационные;</li>

116 <li>2xx - информирование об успешном принятии и обработке клиентской команды;</li>

117 <li>3xx - для успешной обработки требуется сформировать иной query, обычно - по-другому URL;</li>

118 <li>4xx - ошибка client;</li>

119 <li>5xx - ошибка server.</li>

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

121 <h2>Первый проект</h2>

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

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

124 <ol><li>Открыть Spring Boot.</li>

125 <li>Перейти в "Файл"-Новый"-"Проект".</li>

126 <li>Кликнуть по Spring Instializr. Далее выбрать Project SDK.</li>

127 <li>Нажать на "Далее", после чего указать тип проекта - Maven, а также указать Group и Artifact.</li>

128 <li>Продолжить работу с настройками. Здесь предстоит выбрать компоненты фреймворка. Для примера достаточно ресурсов Spring Web.</li>

129 <li>Указать имя проекта и его местоположение.</li>

130 <li>Щелкнуть по "Завершить".</li>

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

132 <h3>О кодах</h3>

133 <p>Теперь необходимо просмотреть код:</p>

134 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/>  </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); } }<h3>REST-функционал</h3>

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

136 <p>Для этого потребуется:</p>

137 <ul><li>Создать new пакет model внутри com,javarush.lectures.rest_example. Внутри "Модель" будет создан класс под названием Client.</li>

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

139 </ul><ul><li>Теперь требуется поработать над реализацией интерфейса. Ключ - это ID Clients, значением - отправляющая request сторона. Это требуется для того, чтобы не перегружать наглядный пример спецификой функционирования БД.</li>

140 <li>В пакете service создается реализация интерфейса clientInterface.</li>

141 </ul><ul><li>Аннотация @Service будет говорить спрингу, что соответствующий класс - это и есть сервис. Относится к специальному типу классов, в которой реализуется бизнес-логика утилиты. Помогает получать экземпляр класса там, где это потребуется.</li>

142 <li>Нужно создать контроллер. Это спецкласс, который будет отвечать за логику обработки queries по ID на эндпоинты.</li>

143 <li>Сначала внедряется зависимость от clientservice.</li>

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

145 </ul><ul><li>Теперь стоит рассмотреть Read id.</li>

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

147 </ul><ul><li>А вот update и delete.</li>

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

149 <h3>Запуск и тестинг</h3>

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

151 <ol><li>Открыть утилиту и создать query.</li>

152 <li>Щелкнуть по кнопке new в левом верхнем углу.</li>

153 <li>Выбрать Request.</li>

154 <li>Дать name оному и сохранить.</li>

155 <li>Отправить request и создать первый клиент.</li>

156 <li>Сформировать несколько подобных элементов.</li>

157 <li>Применить GET.</li>

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

159 <a></a>