В даному матеріалі ми вивчимо основи REST. Спробуємо розглянути, які сервіси називаються RESTful та що таке REST API. Пропоную спочатку розібратись з поняттям REST. Далі я буду наводити дуже спрощені пояснення, оскільки це покращить наше з вами розуміння концепції рест. Для більш детального вивчення, завжди можна погуглити той чи інший термін.
З попередніх матеріалів про те, як працює мережа Інтернет та протокол HTTP, ми дізнались, що клієнт робить запит на сервер і отримує HTML сторінку або медіафайл у відповідь.
Коли гугл карти роблять запит на сервер гугла, їм не потрібен HTML сайт. Їм просто потрібна певна інформація з серверу, яку вони потім оброблять і покажуть користувачеві на власний розсуд. Те саме стосується і певних веб ресурсів. Інколи, потрібно дістати з сервера тільки невелику частину даних і відобразити їх на вже завантаженій сторінці. Інколи, одному додатку на сервері потрібно запросити дані з іншого додатку на іншому сервері. Ці дані йому, як правило, теж не потрібні у вигляді HTML сторінки.
Всі вищеописані сценарії потребують певних протоколів або стандартів комунікації відмінних від HTTP. Як ви вже змогли здогадатись, REST дуже добре підходить для цих цілей. Однак, не слід думати що не існує інших підходів чи протоколів. Їх існує досить багато. Проте, саме через свою простоту, REST займає провідне місце, коли йдеться про комунікацію сервісів.
Історія REST
Почалося все з того, що в 2000 році, один американський інженер Рой Філдінг, захищав свою докторську дисертацію в університеті в Ірвіні, штат Каліфорнія. Тема його дисертації була Architectural Styles and the Design of Network-based Software Architectures. Ще варто зазначити що Рой Філдінг був на той час комп’ютерним вченим і дослідником, одним з авторів протоколу HTTP і Apache HTTP вебсервера. Після його виступу REST почав набирати популярності і вже після 2010-х років посів провідне місце серед існуючих на той момент підходах.
Що ж такого цікавого було в тій десертації, що розробники почали активно використовувати цей підхід? В основі REST (Representational State Transfer) лежить ідея про ресурси, які можна ідентифікувати та звертатися до них за допомогою стандартних методів HTTP (наприклад, GET, POST, PUT, DELETE). Кожен ресурс має унікальний ідентифікатор (URL), і взаємодія з ним відбувається через стандартні HTTP-запити та відповіді. REST спрощує роботу з веб-сервісами та дозволяє легко взаємодіяти з ними за допомогою звичайних веб-браузерів чи інших інструментів.
Принципи (constraints) REST
Зверніть увагу: REST не є протоколом чи фреймворком. Це просто архітектурний стиль, який містить принципи для комунікації в розподіленій архітектурі (клієнт-сервер). Пропоную розглянути ці принципи.
Наявність клієнта і сервера
Шаблон проектування «клієнт-сервер» забезпечує поділ ролей, що допомагає компонентам клієнта та сервера розвиватися незалежно. Ваш бекенд з REST API знаходиться на сервері, а клієнтом може виступати як веб сайт на HTML, мобільний додаток, чи взагалі інший сервер.
Відокремлюючи інтерфейс користувача (клієнт) від проблем зберігання даних (сервер), ми покращуємо переносимість інтерфейсу користувача між кількома платформами та покращуємо масштабованість за рахунок спрощення компонентів сервера. Тепер наш сервер вже не відповідає за формування HTML сторінок як це було наприклад в MVC. Він просто віддає дані. А хто і як ті дані споживатиме йому вже не цікаво.
Принцип stateless
Statelessness передбачає, що кожен запит від клієнта до сервера повинен містити всю інформацію, необхідну для розуміння та виконання запиту. Сервер вже не може зберігати в себе сесії клієнта. Відразу проводимо аналогію з веб додатками за MVC підходом. Там відразу після першого запиту зберігалась сесія. І ми могли отримувати з неї певні дані про клієнта. В REST клієнтська програма повинна повністю зберігати стан сеансу.
Єдині інтерфейси (Uniform interface) для ресурсів
При застосуванні даного принципу ми можемо спростити загальну архітектуру системи та покращити видимість взаємодій.
Наступні чотири обмеження можуть забезпечити єдиний інтерфейс REST:
- Ідентифікація ресурсів – Інтерфейс повинен унікально ідентифікувати кожен ресурс, що бере участь у взаємодії між клієнтом та сервером.
- Маніпулювання ресурсами через представлення – Ресурси повинні мати єдинообразні представлення у відповіді сервера. Користувачі API повинні використовувати ці представлення для зміни стану ресурсу на сервері.
- Самоописуючі повідомлення – Кожне представлення ресурсу повинно нести достатньо інформації для опису обробки повідомлення. Воно також повинно надавати інформацію про додаткові дії, які клієнт може виконати з ресурсом.
- Гіпермедіа як механізм стану застосунку – Клієнт повинен мати лише початковий URI застосунку. Клієнтський застосунок повинен динамічно керувати всіма іншими ресурсами та взаємодіями за допомогою гіперпосилань.
Простіше кажучи, REST визначає стійкий та єдиний інтерфейс для взаємодій між клієнтами та серверами. Наприклад, REST API які базуються на HTTP (а тільки їх ми і будемо розглядати) використовують стандартні методи HTTP (GET, POST, PUT, DELETE і т.д.) та URIs (унікальні ідентифікатори ресурсів) для ідентифікації ресурсів.
Layered-архітектура
Багатошарова архітектура складається з ієрархічних рівнів, обмежуючи поведінку компонентів. У багатошаровій системі кожен компонент не може бачити далі безпосереднього рівня, з яким вони взаємодіють. Ми вже бачили багатошарову архітектуру коли працювали з MVC.
Можливості кешування відповіді сервера
Сервер повинен мати можливості кешувати відповідь. І при повторному запиті від клієнта, повертати кеш.
Сервіс, який дотримується цих 5 принципів може називатись RESTful. Оскільки REST не є протоколом, а просто архітектурним підходом, то можна використовувати будь-який протокол, формат даних або фреймворк для розробки RESTful сервісів. Але традиційно саме протокол HTTP і формат JSON найбільш часто використовуються завдяки своїй простоті.
Принципи вище в деталях знати не обовʼязково. Оскільки ви, скоріше за все, не будете писати REST сервіси з нуля. Ви будете використовувати фреймворки накшталт Spring, де дуже багато всього реалізовано і вам потрібно тільки продумувати бізнес логіку.
REST і JSON
Підозрюю, що багато хто з вас не чув про JSON (JavaScript Object Notation). Це дуже простий для читання та розуміння тестовий формат даних. Саме його, як правило, використовують для передачі даних в REST.
Ось приклад JSON:
{
"name": "abc",
"email": "abc@gmail.com",
"age": 22,
"books": [
{
"bookName": "1984",
"yearOfPublishing": 1966
},
{
"bookName": "Aivengo",
"yearOfPublishing": 1982
}
]
}Дані JSON записуються як пари ім’я/значення.
Пара ім’я/значення складається з назви поля (у подвійних лапках), за якою йде двокрапка та значення. Якщо треба передати масив, тоді обʼєкти масиву поміщаються в квадратні дужки []. Сам обʼєкт поміщається в фігурні дужки {}.
Основні теоретичні моменти з приводу REST ми розібрали. На практиці все виглядає значно простіше і цікавіше. Однак, перед тим, як перейти до практити я пропоную розглянути REST API Naming Conventions.
REST API конвенції
Оскільки REST не є протоколом і є дуже простим, його реалізація не вимагає строгих правил. Це, звісно, породжує дуже багато різних рішень, які складно потім розуміти іншим розробникам. Тому дуже важливо дотримуватись найкращих практик (best practices) при написанні API.
Наразі, при написанні RESTful веб сервісів прийнята така конвенція:
- Назва ресурсу – це іменник (у множині). Такий варіант краще /users/1, ніж /user/1.
- Дія над ресурсом – це HTTP-метод, який вказує клієнт: GET – отримати ресурс, POST – створити ресурс, PUT – оновити ресурс повністю, DELETE — видалити ресурс, PATCH — частково змінити ресурс (ніколи не бачив щоб використовували на практиці).
- Використовуйте малі літери в URI. /users/managed-books краще, ніж /users/managedBooks.
- Не використовуйте назви функцій в іменах урл. Наприклад createUser, update-user. Для позначення функцій слугують HTTP методи: POST /user буде всім зрозуміло що це створення юзера; PUT /user – відповідно оновлення юзера. Це також стосується всіх дієслів. Такий варіант урл НЕ ОК: POST /users/scripts/execute. Краще щось накшталт цього: POST /users/scripts або /users/scripts/status, де в тілі передати статус execute.
- Не використовуйте підкреслення (_) в УРЛ. Слова краще ділити за допомогою дефіс (-).
Вищеописані конвенції є скоріше рекомендацією, ніж суворим правилом. На практиці ви побачите, що багато проєктів дотримуються цих конвенцій частково. Якщо ви тільки починаєте новий проєкт, намагайтесь використовувати best practices щодо конвенцій REST API. Якщо ви прийшли на існуючий проєкт і там вже написано багато коду, який не дуже слідує конвенціям, краще порадитись з колегами чи варто впроваджувати найкращі практики, чи можливо варто дотримуватись вже існуючих на проєкті правил неймінгу.
Це все, що стосується основ REST. Тепер ви знаєте, які сервіси можуть називатись RESTful, та яких правил бажано дотримуватись при написанні REST API. Тепер можна сміливо приступати до практики і писати свої веб сервіси.
Залишити відповідь