1. Підхід Remote API
Усі програмісти роблять ту саму помилку при побудові архітектури клієнт-сервер. Вони починають сприймати запити до сервера як виклик методів.
Ти хочеш запустити процес генерації звіту на сервері, чому б не надіслати йому запит типу:
http://server.com/startDocumentGeneration?params
Як завантажити звіт після того, як він завершиться? Для цього напишемо ще один метод:
http://server.com/getDocument
Сервер HttpSession зберігає інформацію по нашому документу, і щойно документ буде згенерований, сервер його віддасть.
Чудовий підхід, чи не так?
Насправді підхід жахливий. Справа в тому, що сервер повинен запам'ятати номер документа. Іншими словами, щоб правильно обробляти нові виклики методів, сервер повинен запам'ятати результати виклика попередніх методів.
В інтернеті це велика проблема. Інтернет може зникнути, браузер закритися. Сторінку можна перезавантажити або випадково натиснути на посилання, тощо. А сервер продовжуватиме зберігати мегабайти даних із попередніх запитів користувача.
Для комфортної роботи з сервером ви не можете розраховувати, що у вас завжди будуть під рукою дані попередніх запитів до сервера.
Як тоді викликати методи сервера? Правильна відповідь буде жахлива: а ніяк!
2. Підхід REST
Програмісти повернулися до витоків і згадали, що спочатку запит містив шлях до файлу на сервері:
http://server.com/path?params
І вирішили використати цей підхід по максимуму.
Тепер сервер розглядається як сховище даних, що видно назовні у вигляді деякого дерева.
Якщо бажаєте отримати список усіх користувачів, викликайте запит:
http://server.com/users
Якщо бажаєте отримати дані щодо користувача 113, виконуєте запит:
http://server.com/users/113
І так далі, в тому ж ключі.
Проговоримо ще раз: сервер розглядається як сховище даних, які видно назовні у вигляді деякого дерева.
Дані можна отримувати – запити GET, змінювати – запит POST та видаляти – запит DELETE.
3. Відсутність стану
REST-протокол взаємодії між клієнтом та сервером вимагає дотримання наступної умови: у період між запитами від клієнта жодна інформація про стан клієнта на сервері не зберігається.
Усі запити від клієнта потрібно складати так, щоб сервер щоразу отримував всю необхідну інформацію для виконання запиту. Водночас стан сесії зберігається на боці клієнта.
Під час обробки запитів клієнтів вважається, що клієнт перебуває в перехідному стані. Кожен окремий стан програми представлено зв'язками, які можуть бути задіяні під час наступного звернення клієнта.
4. Одноманітність інтерфейсу
Усі шляхи, якими віддаються об'єкти з сервера, стандартизуються. Це дуже зручно, особливо якщо ти отримуєш дані з чужих REST-серверів.
Усі інтерфейси об'єктів повинні дотримуватися трьох умов:
Ідентифікація ресурсів
Усі ресурси ідентифікуються у запитах із використанням URI. Ресурси всередині сервера відокремлені від представлень, які повертаються клієнтам. Наприклад, сервер може надсилати дані з бази даних у вигляді HTML, XML або JSON, жоден з яких не є типом зберігання всередині сервера.
Маніпуляція ресурсами через уявлення
Якщо клієнт зберігає подання ресурсу, включнл з метаданими, він має достатньо інформації для модифікації або видалення ресурсу на сервері.
"Самоописувані" повідомлення
Кожне повідомлення містить достатньо інформації, щоб зрозуміти, як його обробляти. Наприклад, якщо вам потрібна інформація про користувача, сервер поверне вам JSON об'єкт, де будуть поля – ім'я, адреса.
Не повинно бути ситуації, коли клієнт повинен знати, що перше число у відповіді – це вік, а друге – це дата народження.
5. Кешування
Підхід REST передбачає, що запити до даних йдуть за допомогою протоколу HTTP. Тому об'єкти отримуються через виклик GET-запиту. Отже на них, як і на всі ресурси, отримані за допомогою GET-запиту, поширюються всі правила кешування HTTP-ресурсів.
Тобто дані, отримані через API REST, кешуються так само, як і будь-які статичні ресурси на веб-серверах. Краса :)
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ