JavaRush /Java блог /Java Developer /Обзор REST. Часть 1: что такое REST

Обзор REST. Часть 1: что такое REST

Статья из группы Java Developer
Привет, сегодня мы изучим с тобой очень интересную, а главное, востребованную на рынке труда тему — REST. Обзор REST. Часть 1: что такое REST - 1Обзор REST мы разобьем на три части:
  1. В первой части мы коснемся истории возникновения REST и опишем принципы, на которых базируется REST.

  2. Во второй — рассмотрим, как происходит общение между клиентом и сервером по HTTP-протоколу.

  3. В третьей — напишем небольшое RESTful-приложение, которое протестируем с помощью программы Postman.

Статья рассчитана на читателя, знакомого со следующими терминами:
  • HTTP;
  • URL и URI;
  • JSON и в меньшей степени XML;
  • внедрение зависимостей (Dependency Injection).

Часть 1. Что такое REST

REST, как и многое в мире IT, — это акроним, сокращение от английского Representational State Transfer — передача состояния представления. Это архитектурный стиль взаимодействия компонентов распределенной системы в компьютерной сети. Проще говоря, REST определяет стиль взаимодействия (обмена данными) между разными компонентами системы, каждая из которых может физически располагаться в разных местах. Данный архитектурный стиль представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной системы. Эти ограничения иногда называют принципами REST. Их немного, всего 6 штук. О них мы поговорим чуть позже.
Приложения, построенные с учетом REST, т.е. не нарушающие накладываемые REST ограничения, называют RESTful.

История возникновения REST

Термин REST ввел Рой Филдинг, один из создателей протокола HTTP, в своей докторской диссертации "Архитектурные стили и дизайн сетевых программных архитектур" ("Architectural Styles and the Design of Network-based Software Architectures") в 2000 году. Можно сказать, что термин REST еще молодой, хотя его концепция лежит в самой основе всемирной паутины. Мы не будем погружаться глубоко в историю возникновения данного термина. Если хочешь окунуться в первоисточники, загляни в диссертацию Филдинга.

REST ограничения и принципы

Как было сказано выше, REST определяет, как компоненты распределенной системы должны взаимодействовать друг с другом. В общем случае это происходит посредством запросов-ответов. Компоненту, которая отправляет запрос называют клиентом; компоненту, которая обрабатывает запрос и отправляет клиенту ответ, называют сервером. Запросы и ответы, чаще всего, отправляются по протоколу HTTP (англ. HyperText Transfer Protocol — "протокол передачи гипертекста"). Как правило сервер — это некое веб-приложение. Клиентом же может быть не то чтобы что угодно, но довольно многое. Например, мобильное приложение, которое запрашивает у сервера данные. Либо браузер, который отправляет запросы с веб-страницы на сервер для загрузки данных. Приложение А может запрашивать данные у приложения Б. Тогда А является клиентом по отношению к Б, а Б — сервером по отношению к А. Одновременно с этим, А может обрабатывать запросы от В, Г, Д и т.д. В таком случае, приложение А является одновременно и сервером, и клиентом. Все зависит от контекста. Однозначно одно: компонента которая шлет запрос — это клиент. Компонента, которая принимает, обрабатывает и отвечает на запрос — сервер. Однако не каждая система, чьи компоненты обмениваются данными посредством запросов-ответов, является REST (или же RESTful) системой. Чтобы система считалась RESTful, она должна “вписываться” в шесть REST ограничений:

1. Приведение архитектуры к модели клиент-сервер

В основе данного ограничения лежит разграничение потребностей. Необходимо отделять потребности клиентского интерфейса от потребностей сервера, хранящего данные. Данное ограничение повышает переносимость клиентского кода на другие платформы, а упрощение серверной части улучшает масштабируемость системы. Само разграничение на “клиент” и “сервер” позволяет им развиваться независимо друг от друга.

2. Отсутствие состояния

Архитектура REST требует соблюдения следующего условия. В период между запросами серверу не нужно хранить информацию о состоянии клиента и наоборот. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Таким образом и сервер, и клиент могут "понимать" любое принятое сообщение, не опираясь при этом на предыдущие сообщения.

3. Кэширование

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

4. Единообразие интерфейса

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

5. Слои

Под слоями подразумевается иерархическая структура сетей. Иногда клиент может общаться напрямую с сервером, а иногда — просто с промежуточным узлом. Применение промежуточных серверов способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования. Приведем пример. Представим себе некоторое мобильное приложение, которое пользуется популярностью во всем мире. Его неотъемлемая часть — загрузка картинок. Так как пользователей — миллионы человек, один сервер не смог бы выдержать такой большой нагрузки. Разграничение системы на слои решит эту проблему. Клиент запросит картинку у промежуточного узла, промежуточный узел запросит картинку у сервера, который наименее загружен в данный момент, и вернет картинку клиенту. Если здесь на каждом уровне иерархии правильно применить кэширование, то можно добиться хорошей масштабируемости системы.

6. Код по требованию (необязательное ограничение)

Данное ограничение подразумевает, что клиент может расширять свою функциональность, за счет загрузки кода с сервера в виде апплетов или сценариев.

Преимущества, которые дает REST

У приложений, которые соблюдают все вышеперечисленные ограничения, есть такие преимущества: надёжность (не нужно сохранять информацию о состоянии клиента, которая может быть утеряна);
  • производительность (за счёт использования кэша);
  • масштабируемость;
  • прозрачность системы взаимодействия;
  • простота интерфейсов;
  • портативность компонентов;
  • лёгкость внесения изменений;
  • способность эволюционировать, приспосабливаясь к новым требованиям.
Часть 2: коммуникация между клиентом и сервером Часть 3: создание RESTful сервиса на Spring Boot
Комментарии (13)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Максим Li Уровень 36
17 ноября 2023
Хорошая статья!
IwanIV Уровень 41
24 января 2022
Скажите, от куда вы взяли эту статью? Ссылку можно? Или она родилась в недрах лаборатории JR?
14 июля 2021
 @Admins в тексте, раздел Преимущества, которые дает REST надо загнать под булит строку "надежность..."
hidden #1983828 Уровень 35
27 ноября 2020
Поооочему поочему вы делаете компонент женского рода?
Daniil Vishnivetsky Уровень 9
11 ноября 2020
А есть книги по этой теме? Можете посоветовать?
Pavel Kurchavov Уровень 32
22 октября 2020
Пока что лучшее объяснение темы, которое нашел в ру сегменте
Евгений Уровень 20
27 января 2020
Пока все понятно, спасибо.
Hexronimo Уровень 27
23 января 2020
Как раз сейчас пишу его со SpringBoot, чтобы быстрее делать отчеты для работы, правда еще и Vue приходится использовать, который меня пока подбешивает)
Андрей Киров Уровень 32
22 января 2020
Положил в закладки - вечером почитаю.
Timur Уровень 18
20 января 2020
nice