REST

REST (REpresentational State Transfer) - передача репрезентативного стану.

По суті це принципи проєктування аби збільшення масштабованості мережевих комунікацій.

Основні питання на які відповідає REST:

• Які компоненти системи?

• Як вони комунікують між собою?

• Як змінити різні частини системи у будь-який час?

• Як масштабувати систему для обслуговування великої кількості користувачів?

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

URI та URL?

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

URL - особливий тип ідентифікатора. URI це ширше поняття, яке містить в собі URL.

URL містить конкретний шлях до файлу. і ц його назві вказується протокол (https, ftp тощо)

Схема формування запиту URL:

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

Приклад:

http://user:[e-mail]:80/resourse/path/?query=name&ttt=123#hash

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

• scheme - мережевий протокол, за яким відбувається звернення до ресурсу

• login - ім'я користувача, яке використовується для доступу до ресурсу (не обов'язковий параметр)

• password - пароль користувача, якщо він необхідний

• host - доменне ім'я хоста в системі DNS (google.com) або IP-адреса хоста у формі чотирьох груп десяткових чисел, розділених крапками

• port - порт хоста для підключення, Наприклад у записі http://localhost:3000 3000 - це і є порт. Для веб-браузера порт за замовчанням 443. Він підставляється автоматично. Можна вказати специфічний порт.

• path - додаткова інформація про розміщення ресурсу.

• query - рядок запиту з переданими на сервер (методом GET) параметрами. Починається із символу ?, роздільник параметрів - знак &. Приклад: ?category=electronics&department=123

• fragment - ідентифікатор із символом # напочатку. Часто його називають хеш - hash або якір. Якорем може бути вказаний заголовок усередині документа або атрибут id елемента. Якщо вказаний якір, то браузер відкриє сторінку та перемістить вікно перегляду на вказаний елемент. Наприклад, посилання на секцію контактів у лендингу: https://example.com/#contact.

Обмеження REST

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

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

Stateless​

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

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

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

• ідентифікація ресурсів

• маніпулювання ресурсами за допомогою уявлень

• інформативні (самоописові) повідомлення

• гіпермедіа.

Ідентифікація ресурсів​

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

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

Маніпулювання ресурсами через уявлення​

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

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

Інформативні (self-descriptive) повідомлення​

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

Наприклад, коли користувач вводить 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>Site Title</title>
  </head>
  <body>
    Hello world!
    <a href="https://google.com>Google</a>
    <img src="https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png">
  </body>
</html>

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

Гіпермедіа​

Гіпермедіа – це дані, які надсилаються з сервера клієнту. Вони містять інформацію про те, що клієнт може зробити далі, іншими словами, які подальші запити може робити. Наприклад запит:

<a href="https://google.com>Google</a>

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

<img src="https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png">

повідомляє клієнта, що потрібно негайно надіслати GET-запит на https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png, щоб він міг відобразити зображення користувачеві.

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

Кешування​

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

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

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

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

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

Покликання:

Як працює REST API