REST - makstron/info GitHub Wiki

REST - (скор. Representational State Transfer «передача репрезентативного стану») — підхід до мережевих протоколів, які надають доступ до інформаційних ресурсів.

Стандарт HTTP визначає 8 типів повідомлень

Основні

GET — отримати представлення ресурсу
DELETE — знищити ресурс
POST — створити новий ресурс на місці даного використавши значення запиту
PUT — замінити стан поточного ресурсу станом, що описується запитом
PATCH — змінити лише частину цього ресурсу. Якщо якась частина ресурсу не згадується в запиті — не чіпати її. Знижує кількість інформації, яку потрібно передавати.

Щоб Дослідити API

HEAD — отримати заголовки, які б відсилались разом з представленням цього ресурсу, але не саме представлення.
OPTIONS — визначити список методів, на які цей ресурс відповідає.

HTTP-проксі

CONNECT - використовуються лише для HTTP-проксі
TRACE - використовуються лише для HTTP-проксі

LINK — прив'язати певний ресурс до цього
UNLINK — відв'язати ресурс від цього

Методи GET, PUT та DELETE — ідемпотентні, що означає, що незалежно від того, скільки разів ви виконаєте операцію, яку вони просять, — ви отримаєте той самий результат. POST — не ідемпотентний, тобто, відправивши POST на створення повідомлення кілька разів, ви отримаєте кілька повідомлень.

GET

DELETE

POST

PUT

PATCH

HEAD

OPTIONS

Согласно стандарту HTTP/1.1 метод OPTIONS может быть использован клиентом для определения параметров или требований, связанных с ресурсом. Сервер также может отправлять документацию в удобочитаемом формате. Ответ на запрос OPTIONS может содержать список допустимых методов для данного ресурса в хедере Allow.

HTTP/1.1 200 OK
Allow: GET,POST,DELETE,OPTIONS
Content-Length: 0

Перед нами стоит задача разработки пользовательского интерфейса. Грубо говоря, нам надо в определённый момент решить, каким образом мы будем прятать или показывать кнопку Delete в зависимости от полномочий текущего пользователя.

Можно получать знания о полномочиях из сервиса и реализовывать логику на стороне клиента. Но это плохой подход.

В REST-архитектуре клиент и сервер должны быть максимально независимыми. Не дело клиента выяснять, какими полномочиями должен обладать пользователь, чтобы иметь возможность удалить документ. Если клиент будет реализовывать свою логику, то изменение механизма полномочий на сервере приведёт, скорее всего, к необходимости изменений на клиенте.

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

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

Обмеження вимагає розділення відповідальності між компонентами, які займаються зберіганням/оновленням даних (сервером), і тими компонентами, які займаються відображенням даних на інтерфейсі користувача та реагування на дії з цим інтерфейсом (клієнтом). Таке розділення дозволяє компонентам еволюціонувати незалежно.

Відсутність стану

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

(+) покращує масштабовність
(+) спрощується моніторинг
(+) збільшується надійність
(-) знижується продуктивність

Кешування

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

Однорідний інтерфейс

Шари абстракції

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

Запитування коду

https://uk.wikipedia.org/wiki/REST https://habr.com/ru/articles/342432/