В архітектурі «Клієнт-Сервер» кілька комп'ютерів-клієнтів (віддалені системи) надсилають запити і отримують послуги від централізованої службової машини – сервера (server – англ. «офіціант, обслуга»). Більш детально про клієнт-серверну архітектуру можна дізнатися в статті нашого блогу.
Веб-браузери взаємодіють з веб-серверами за допомогою протоколу передачі гіпертексту (HTTP). Коли відбувається натискання посилання на сторінці, заповнюється форма або робиться пошук, браузер відправляє на сервер HTTP-запит.
HTTP (Hypertext Transfer Protocol) – це протокол передачі гіпертексту, який дозволяє клієнту та серверу спілкуватися по мережі за допомогою запиту/відповіді. Це протокол рівня додатка, який покладається на TCP/IP для своїх послуг. HTTPS – це розширення протоколу передачі гіпертексту. Він використовується для безпечного спілкування через комп’ютерну мережу. Протокол HTTP для передачі запитів і відповідей також використовується під час роботи з API.
API (Application Programming Interface) забезпечує взаємодію між двома системами. API дозволяє надсилати інформацію безпосередньо з однієї програми до іншої, обминаючи інтерфейс взаємодії з користувачем. Це автономна функція, яка не залежить від інших служб. При натисканні на кнопку в інтерфейсі, запускаються внутрішні функції, щоб передати і отримати інформацію. API приймає запит, передає інформацію системі, обробляє її та повертає відповідь.
Щоб між програмами виникала взаємодія, їх API потрібно побудувати за єдиним стандартом. Одним з них є REST (REpresentational State Transfer) – стандарт архітектури взаємодії додатків і сайтів, що використовує протокол HTTP. Особливість REST в тому, що сервер не запам'ятовує стан користувача між запитами. Іншими словами, ідентифікація користувача і всі параметри виконання операції передаються в кожному запиті.
Взагалі REST охоплює більш широку область, ніж HTTP – його можна застосовувати і в інших мережах з іншими протоколами. REST описує принципи взаємодії клієнта і сервера, засновані на поняттях «ресурсу» і «дієслова» (можна розуміти їх як підмет і присудок). У випадку з HTTP ресурс визначається своїм URI, а дієслово – це HTTP-метод.
В архітектурі REST клієнти надсилають запити на отримання або модифікацію ресурсів, а сервери надсилають відповіді на ці запити. Розглянемо стандартні способи подання запитів і надсилання відповідей.
Оформлення запитів
REST вимагає, щоб клієнт зробив запит до сервера, щоб отримати або змінити дані на сервері. Запит зазвичай складається з:
- дієслова HTTP, яке визначає, яку операцію виконувати;
- заголовка, який дозволяє клієнту передавати інформацію про запит;
- шляху до ресурсу;
- необов'язкового тіла повідомлення, що містить дані.
Є 4 основних дієслова HTTP, які використовуються в запитах для взаємодії з ресурсами в системі REST:
- GET – отримати певний ресурс (за ідентифікатором) або набір ресурсів;
- POST – створити новий ресурс;
- PUT – оновити певний ресурс (за ідентифікатором);
- DELETE – видалити певний ресурс за ідентифікатором.
У заголовку запиту клієнт надсилає тип вмісту, який він може отримати від сервера. Це називається полем Accept, і воно гарантує, що сервер не надсилає дані, які клієнт не може зрозуміти чи обробити. Варіантами для типів вмісту є типи MIME (багатоцільові розширення Інтернет-пошти).
Типи MIME, які використовуються для визначення типів вмісту в полі Accept, складаються з type та subtype. Вони відокремлюються косою рискою (/).
Наприклад, текстовий файл, що містить HTML, буде вказано з типом text/html. Якби цей текстовий файл містив CSS, він був би вказаний як text/css. Загальний текстовий файл буде позначено як text/plain. Це значення за замовчуванням, але воно не єдине. Якщо клієнт очікує text/css і отримує text/plain, він не зможе розпізнати вміст.
Інші типи та часто використовувані підтипи:
- image – image/png, image/jpeg, image/gif;
- audio – audio/wav, audio/mpeg;
- video – video/mp4, video/ogg;
- application – application/json, application/pdf, application/xml, application/octet-stream.
Наприклад, клієнт, який отримує доступ до ресурсу з id 23 у ресурсі статей на сервері, може надіслати запит GET, наприклад:
Поле заголовка Accept у цьому випадку говорить про те, що клієнтом буде прийнято зміст (контент) у text/html або application/xhtml.
Запити мають містити шлях до ресурсу, на якому повинна виконуватися операція. В API REST шляхи повинні бути розроблені для допомоги клієнту відслідковувати події.
Умовно перша частина шляху має бути формою множини ресурсу. Це робить вкладені шляхи простими для читання та зрозумілості.
Шлях на кшталт kidsfashion.com/customers/145/orders/17 зрозумілий кожному користувачу, оскільки він є ієрархічним та описовим. На прикладі вказано, що отримується доступ до замовлення з ідентифікатором 17 для клієнта з ідентифікатором 145.
Звертаючись до списку або колекції ресурсів, не завжди потрібно додавати ідентифікатор. Наприклад, запит POST до шляху kidsfashion.com/customers не потребує додаткового ідентифікатора, оскільки сервер генерує ідентифікатор для нового об’єкта.
Якщо ми намагаємося отримати доступ до одного ресурсу, нам потрібно буде додати ідентифікатор до шляху. Наприклад: GET kidsfashion.com/customers/:id – отримується елемент у ресурсі клієнтів із зазначеним ідентифікатором. DELETE kidsfashion.com/customers/:id – видаляється елемент із ресурсу клієнтів із зазначеним ідентифікатором.
Тестування АРІ
API також має тестуватись. Під час тестування перевіряються інтерфейси прикладного програмування. Метою тестування API є перевірка функціональності, надійності, продуктивності та безпеки інтерфейсів програмування. У тестуванні API замість використання стандартних запитів/висновків (використовуючи клавіатуру та ін.) використовується програмне забезпечення для відправки запитів API, отримання та запису відповіді системи. Тести API відрізняються від тестів GUI і не фокусуються на зовнішньому вигляді програми. Взагалі, таке тестування концентрується на рівні бізнес-логіки в архітектурі програмного забезпечення.
Тестування API відноситься до інтеграційного тестування, а значить в ході нього можна відслідкувати помилки взаємодії між модулями системи або між системами. Для тестування використовують спеціальні інструменти, де можна відправити вхідні дані в запиті і перевірити точність вихідних даних.
Postman – це HTTP-клієнт для тестування API. Користуючись Postman можливо:
- Складати і відправляти HTTP-запити;
- Створювати колекції та папки запитів для скорочення часу на тестування;
- Змінювати параметри запитів;
- Додавати до виклику API контрольні точки;
- Змінювати оточення для одних і тих же запитів;
- Проводити автоматизоване тестування API з колекції запитів за допомогою Collection Runner.
Для роботи із серверами програма Postman використовує протокол HTTP. Тестувальник відправляє тестові запити від клієнта на сервер та отримує відповідь, чи є помилка в роботі API.
Postman доступний у вигляді додатку для ОС Windows, macOS та Linux, а також в веб-версії https://www.postman.com/.
В статті розглянемо запити GET, PUT та відповіді на них. Щоб створити запит, потрібно натиснути кнопку New і вибрати пункт HTTP Request.
Необхідно створити колекцію в якій будуть зберігатись запити Postman. Всередині колекції запити можна об'єднати в папки, наприклад, за різними версіями API або тестованими елементами програми.
Створити запит натисканням кнопки «Add requests».
GET
Виконаємо запит на отримання даних про створеного користувача, вибираємо GET.
Вказати url сайту, що тестується https://reqres.in/ (див. більше прикладів запитів та відповідей). На більшості реальних сайтів API закритий (з метою збереження безпеки) тому протестувати сторонньому користувачу його неможливо.
Прописати назву відповідного API, у даному випадку /api/users/2.
У вкладці «Body» вибрати raw.
Далі вибрати формат тексту JSON (JavaScript Object Notation – текстовий формат обміну даними на мові JavaScript). Натиснути кнопку «Send».
Відображаються фактичні дані про користувача, які необхідно порівняти з очікуваними.
PUT
Спробуємо оновити дані користувача, створюючи для цього update_user. Обрати запит PUT.
Вказати дані та відправити їх.
В результаті відображається зазначений час оновлення та відповідь 200 (успішна) від сервера.
Тестування API стає все більш затребуваним. За допомогою тестування API можна передбачити як буде реагувати система на реального користувача, виконати одні й ті ж тести з різноманітними наборами вхідних даних, зробити будь-які допоміжні дії зі створення тестових даних та ситуацій і таким чином пришвидшити тестування та зробити його більш якісним.
