Огляд REST. Частина 1: що таке

Привіт сьогодні ми вивчимо з тобою дуже цікаву, а головне, затребувану на ринку праці тему — REST. Огляд 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 ввів Рой Філдінг, один із творців протоколу 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