Перейти до основного вмісту

Що таке REST

Вступ​

REST (REpresentational State Transfer) - розшифровується як передача репрезентативного стану. Це набір принципів проектування для підвищення масштабованості та гнучкості мережевих комунікацій. Ці принципи відповідають на ряд питань.

  • Які компоненти системи?
  • Як вони спілкуються між собою?
  • Як можна гарантувати, можливість змінити різні частини системи у будь-який час?
  • Як можна масштабувати систему для обслуговування великої кількості користувачів?

Рой Т. Філдінг вперше ввів термін REST у 2000 році у своїй докторській дисертації «Архітектурні стилі та проектування мережевих архітектур програмного забезпечення". Її можна почитати за цією адресою

На момент публікації дисертації Інтернет уже був дуже популярним. Філдінг по суті зробив крок назад і проаналізував риси, які зробили Інтернет більш успішнішим, ніж конкуруючі Інтернет-протоколи. Потім він представив схематичну структуру, яка зробить мережеве спілкування "веб-подібним". Отже, REST – це загальний набір принципів, не специфічних для Інтернету. Його можна застосовувати до інших типів мереж, наприклад, до вбудованих систем. REST також не є протоколом, оскільки вимагає подробиць реалізації. У дисертації Філдінг викладає ряд архітектурних обмежень, яким має задовольняти система, щоб вважатися RESTful.

Що таке URI та URL?​

Перш ніж ми перейдемо до того, які архітектурні обмеження накладає REST, давайте розберемося з термінологією URL та URI. Терміни URI та URL часто використовуються як синоніми, але це не зовсім одне й те саме.

URI

Є ідентифікатором конкретного ресурсу. Як сторінку, книгу або документ.

URL

Представляє особливий тип ідентифікатора, який також говорить вам, як отримати до нього доступ

В принципі URI це ширше поняття і включає у собі URL. Якщо проводити якісь аналогії спрощення то можна вважати, що URI це щось на зразок імені, а URL конкретно ім'я як до нього добраться. Наприклад ISBN книги це URI, а ось https://goit.ua це URL тут є ім'я і як до нього дійти - протокол. Тобто. якщо протокол (https, ftp і т.д.) або присутній, або мається на увазі для домену, ви повинні називати його URL-адресою, навіть якщо це також URI.

Існує наступна традиційна форма запису `URL:

<scheme>://[<login>[:<password>]@]<host>[:<port>]][/<path>][?<query>][#<fragment>]

Приклад:

http://user:password@host.com:80/resourse/path/?query=name&ttt=123#hash

У цьому записі:

  • scheme - Це мережевий протокол, за яким відбувається звернення до ресурсу
  • login - не обов'язковий параметр ім'я користувача, яке використовується для доступу до ресурсу
  • password - пароль вказаного користувача, якщо він необхідний
  • host - повністю прописане доменне ім'я хоста в системі DNS (goit.ua) або IP-адреса хоста у формі чотирьох груп десяткових чисел, розділених крапками
  • port - порт хоста для підключення, згадайте ми часто використовували http://localhost:3000 де 3000 це і є порт. Виникає закономірне питання, чому порт не вказується наприклад для URL у браузері. Просто браузер знає, що для протоколу http порт дорівнює 80, а для https він дорівнює 443 і підставляє його за нас
  • path - уточнююча інформація про місцезнаходження ресурсу.
  • query - рядок запиту з переданими на сервер (методом GET) параметрами. Починається із символу ?, роздільник параметрів - знак &. Приклад: ?foo=123&baz=234&bar=value
  • fragment - ідентифікатор із попереднім символом #. Часто його називають хеш - hash або якір. Якорем може бути вказаний заголовок усередині документа або атрибут id елементу. За таким посиланням браузер відкриє сторінку та перемістить вікно перегляду вказаного елемента. Наприклад, посилання на секцію контактів у лендинг: https://example.com/#contact.

Архітектурні обмеження RESTful​

Клієнт-сервер​

Перше обмеження вказує, що мережа має складатися із клієнтів та серверів. Сервер - це комп'ютер, який має цікаві ресурси, а клієнт - це комп'ютер, який хоче взаємодіяти з ресурсами, що зберігаються на сервері. Коли ви переглядаєте Інтернет, ваш комп'ютер діє як клієнт і відправляє HTTP-запити на сервер для доступу до інформації та управління нею. Система RESTful повинна працювати за моделлю клієнт-сервер, навіть якщо компонент іноді діє як клієнт, а іноді як сервер.

Альтернативою клієнт-серверної архітектури, відмінної від RESTful, є архітектура інтеграції з урахуванням подій. У цій моделі кожен компонент безперервно транслює події, при цьому очікуючи на відповідні події від інших компонентів. Немає особистого спілкування, тільки трансляція та підслуховування. REST вимагає індивідуальної взаємодії, тому архітектура інтеграції на основі подій не буде RESTful.

Stateless​

Відсутність стану. Відсутність стану не означає, що сервери та клієнти не мають стану, це просто означає, що їм не потрібно відстежувати стан один одного. Коли клієнт не взаємодіє із сервером, сервер не знає про його існування. Сервер також не веде облік попередніх запитів. Кожен запит сприймається як окремий, тобто, жодних сесій.

Єдиний інтерфейс​

Це обмеження гарантує, що існує спільна мова між серверами та клієнтами, яка дозволяє замінювати чи змінювати кожну частину без порушення роботи всієї системи. Це досягається за рахунок 4 додаткових обмежень:

  • ідентифікація ресурсів
  • маніпулювання ресурсами за допомогою уявлень
  • інформативні (самоописові) повідомлення
  • гіпермедіа.

Перше обмеження інтерфейсу: ідентифікація ресурсів​

Перше обмеження єдиного інтерфейсу впливає на спосіб ідентифікації ресурсів. В термінах REST ресурсом може бути будь-що - документ HTML, зображення, інформація про замовлення і т. д. Кожен ресурс має бути однозначно ідентифікований стабільним ідентифікатором «Стабільний» ідентифікатор означає, що він не змінюється при взаємодії, і він не змінюється навіть за зміни стану ресурсу. Якщо ресурс дійсно переміщується на інший ідентифікатор, сервер повинен дати клієнту відповідь, що вказує, що запит був невірним, і дати йому посилання на нове розташування ресурсу.

Інтернет використовує URL для ідентифікації ресурсів та HTTP в якості стандарту зв'язку. Щоб отримати ресурс, який зберігається на сервері, клієнт відправляє HTTP-запит GET на URL, який ідентифікує цей ресурс. Щоразу, коли ви вводите адресу у свій браузер, ваш браузер робить запит GET на цей URL. Якщо він отримує статус 200 та HTML-документ, він відображає сторінку у вікні, щоб ви могли її переглянути.

Друге обмеження інтерфейсу: маніпулювання ресурсами через уявлення​

Друге обмеження свідчить, що клієнт керує ресурсами, відправляючи подання на сервер - зазвичай це об'єкт JSON або XML, який містить контент, який він хотів би додати, видалити чи змінити. В REST сервер повністю контролює ресурси та відповідає за будь-які зміни. Ресурсами можуть служити записи у базі даних, файли тощо. Коли клієнт бажає внести зміни в ресурси, він відправляє серверу уявлення про те, як має виглядати одержаний ресурс. Сервер приймає запит як пропозицію, але має повний контроль і сам набуває чинності.

Найпростіший приклад це блог у мережі. Коли користувач створює нове повідомлення у блозі комп'ютер-клієнт повідомляє серверу, що необхідно додати нове повідомлення у блог. Для цього він відправляє HTTP-запит POST, можливо PUT з контентом для нового повідомлення у блозі. Сервер надсилає відповідь клієнту, яка вказує, чи було створено повідомлення або виникла проблема створення запису.

Третє обмеження інтерфейсу: інформативні (self-descriptive) повідомлення​

Інформативні повідомлення - ще одне обмеження, що забезпечує одноманітний інтерфейс між клієнтами та серверами. Інформативне повідомлення - це повідомлення, яке містить всю інформацію, яка потрібна одержувачу для його розуміння. Додаткову інформацію в окремій документації або в іншому повідомленні не повинно бути.

Щоб зрозуміти, як це стосується Інтернету, давайте проаналізуємо набір HTTP-запитів та відповідей.

Коли користувач вводить http://www.example.com в адресному рядку свого веб-браузера, браузер надсилає наступний HTTP-запит:

GET / HTTP/1.1
Host: www.example.com

Це повідомлення є інформативним, оскільки воно повідомляє серверу, який метод HTTP був використаний, і який протокол використовувався (HTTP 1.1).

Сервер може надіслати відповідь, подібну до цього:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>Your Site Title Here</title>
  </head>
  <body>
    Hello world!
    <a href="https://goit.ua">GoIT world!</a>
    <img src="https://goit.ua/wp-content/themes/1/images/Layer.png">
  </body>
</html>

Це повідомлення є інформативним (самоописним), тому що воно повідомляє клієнту, як йому потрібно інтерпретувати тіло повідомлення, вказуючи, що це Content-type було text/html. У клієнта є все необхідне в цьому єдиному повідомленні, щоб обробити його належним чином.

Четверте обмеження інтерфейсу: гіпермедіа​

Останнє обмеження інтерфейсу – це обмеження гіпермедіа. Гіпермедіа – це модне слово для даних, що надсилаються з сервера клієнту, які містять інформацію про те, що клієнт може зробити далі, іншими словами, які подальші запити може робити. В REST сервери повинні надсилати клієнтам тільки гіпермедіа. HTML - це різновид гіпермедіа. Щоб краще зрозуміти це, давайте ще раз подивимося на відповідь сервера вище.

<a href="https://goit.ua">GoIT world!</a>

повідомляє клієнту, що він має зробити запит GET на https://goit.ua, якщо користувач клацне посилання.

<img src="https://goit.ua/wp-content/themes/1/images/Layer.png" />

повідомляє клієнта, що потрібно негайно надіслати запит GET на https://goit.ua/wp-content/themes/1/images/Layer.png, щоб він міг відобразити зображення користувачеві.

Коли система має ідентифікатори кожного ресурсу, маніпулює ними шляхом надсилання уявлень від клієнта на сервер і має повідомлення, які є інформативними і складаються з гіпермедіа, вважається, що вона має єдиний інтерфейс.

Кешування​

Кешування відноситься до обмеження, при якому відповіді сервера повинні бути позначені як кешуються або некешуються. Кешування відбувається, коли клієнт зберігає попередні відповіді, отримані від сервера, тому, коли ці дані знову знадобляться, він може не робити запит через мережу, а використовувати кешовані дані. Кешування частково або повністю усуває деякі клієнт-серверні взаємодії, сприяючи масштабованості та продуктивності програми.

Багатошарова (багаторівнева) система​

Багатошарова (багаторівнева) система полягає в тому, що компонентів може бути більше, ніж просто серверів та клієнтів. Це означає, що у системі може бути більше рівня. Однак кожен компонент обмежений, щоб бачити і взаємодіяти лише з наступним шаром. Проксі – це додатковий компонент, який передає HTTP-запити на сервери чи інші проксі. Проксі-сервери корисні для балансування навантаження та перевірки безпеки. Проксі-сервер діє як сервер для початкового клієнта, який відправляє запит, а потім діє як клієнт, коли передає цей запит далі. Шлюз може бути ще одним додатковим шаром, що переводить HTTP-запит в інший протокол і розповсюджує цей запит, а потім перетворює отриману відповідь назад у HTTP. Клієнт при цьому взаємодіє зі шлюзом як із звичайним сервером.

Код за запитом​

Необов'язкове обмеження, яке стосується можливості сервера відправляти код, що виконується клієнту. Коли документ HTML завантажено, браузер автоматично завантажує код JavaScript з сервера та виконує його локально.

Підсумок​

Таким чином, система RESTful - це будь-яка мережа, що задовольняє розглянутим обмеженням. Система RESTful має бути гнучкою для різних випадків використання, що масштабується для підтримки великої кількості користувачів та компонентів і адаптується з часом. Але пам'ятайте, що REST - це теоретичний проект.