REST означає Representational State Transfer, термін, запропонований Роєм Філдінгом у 2000 році. Це стиль архітектури для проектування слабозв’язаних програм у мережі, який часто використовується під час розробки веб-служб .
REST не нав’язує жодних правил щодо того, як це має бути реалізовано на нижчому рівні, він лише встановлює керівні принципи проектування високого рівня та залишає нас думати про нашу власну реалізацію.
Давайте почнемо зі стандартного дизайну, щоб зрозуміти, що «Рой Філдінг» хоче щоб ми створили. Потім ми обговоримо мої думки, які стосуватимуться тонкощів під час розробки ваших RESTful API.
REST це про архітектурні обмеження
REST визначає 6 архітектурних обмежень , які роблять будь-який веб-сервіс справді RESTful API.
1. Уніфікований інтерфейс
Оскільки у самій назві присутні обмеження, ви ПОВИННІ визначити інтерфейс API для ресурсів усередині системи, які доступні для споживачів API і яких слід дотримуватися. Ресурс у системі повинен мати лише один логічний URI, який повинен забезпечувати спосіб отримання пов’язаних або додаткових даних. Завжди краще синонімізувати та зіставити ресурс із веб-сторінкою.
Будь-який окремий ресурс не повинен бути занадто великим і містити все без винятку в своєму представленні. За потреби ресурс має містити посилання (HATEOAS – «Hypermedia As The Engine Of Application State» або Гіпермедіа як двигун стану програми), що вказують на відносні URI для отримання відповідної інформації.
Крім того, представлення ресурсів у всій системі має відповідати певним вказівкам, таким як правила іменування, формати посилань або формат даних (XML або/або JSON).
Усі ресурси мають бути доступні за допомогою загального підходу, такого як HTTP GET, і аналогічно змінені за допомогою узгодженого підходу.
Після того, як розробники стають знайомими з одним з наших APIs, наш API у структурі та принципах повинен використовуватись до наступного прикладного рішення для інших наших API.
2. Клієнт–сервер
Це обмеження по суті означає, що клієнтські програми та серверні програми ПОВИННІ мати можливість розвиватися окремо без жодної залежності одна від одної. Клієнт повинен знати лише URI ресурсів, і це все. Сьогодні це стандартна практика веб-розробки, тому з вашого боку не потрібно нічого вигадливого. Не ускладнювати.
Сервери та клієнти також можуть бути замінені та розроблені незалежно, якщо інтерфейс між ними не змінено.
3. Stateless – стан не зберігається на сервері.
Рой Філдінг черпав натхнення з HTTP, тому це відображається в цьому обмеженні. Зробити всі взаємодії клієнт-сервер без збереження його стану. Сервер не зберігатиме нічого про останній запит HTTP, зроблений клієнтом. Він розглядатиме кожен запит як новий. Ні сесії, ні історії.
Якщо клієнтська програма має бути програмою з відстеженням стану для кінцевого користувача, де користувач входить один раз і виконує інші авторизовані операції після цього, тоді кожен запит від клієнта повинен містити всю інформацію, необхідну для обслуговування запиту, включаючи автентифікацію та деталі авторизації.
Контекст клієнта не повинен зберігатися на сервері між запитами. Клієнт несе відповідальність за управління станом програми.
4. Кешування
У сучасному світі кешування даних і відповідей має величезне значення, де б це не було застосовано/можливо. Веб-сторінка, яку ви тут читаєте, також є кешованою версією сторінки HTML. Кешування покращує продуктивність на стороні клієнта та покращує можливості масштабування для сервера, оскільки навантаження було зменшено та ми будемо мати більше віддачі від того ж самого серверного обладнання.
У REST кешування має застосовуватися до ресурсів, коли це можливо, і тоді ці ресурси повинні оголосити, що їх можна кешувати. Кешування може бути реалізовано на стороні сервера або клієнта.
Добре кероване кешування частково або повністю усуває деякі взаємодії клієнт-сервер, ще більше покращуючи масштабованість і продуктивність.
5. Багатошарова структура
REST дозволяє використовувати багаторівневу архітектуру системи, де ви розгортаєте API на сервері A, зберігаєте дані на сервері B і автентифікуєте запити на сервері C, наприклад. Зазвичай клієнт не може визначити, чи підключений він безпосередньо до кінцевого сервера чи до посередника.
6. Код на вимогу (опціонально)
Що ж, це обмеження необов’язкове. У більшості випадків ви надсилатимете статичні представлення ресурсів у формі XML або JSON. Але коли вам потрібно, ви можете повернути код який можна виконати щоб підтримувати частину вашої програми, наприклад, клієнти можуть викликати ваш API, щоб отримати код візуалізації віджетів інтерфейсу користувача. Це дозволено.
Усі наведені вище обмеження допоможуть вам створити справді RESTful API, і вам слід їх дотримуватися. Тим не менш, іноді ви можете виявити, що порушуєте одне або два обмеження. Не хвилюйся; ви все ще створюєте RESTful API, але не «true RESTful».
Зауважте, що всі наведені вище обмеження найбільш тісно пов’язані з WWW (мережею). Використовуючи RESTful API, ви можете робити зі своїми веб-службами те саме, що й із веб-сторінками.