Поширені помилки API та способи їх усунення

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

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

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

Наприклад, користувач хоче додати якийсь товар у кошик, натискає відповідну кнопку, яка запускає запит API, отримує відповідь, і кошик оновлюється. Якщо цей запит не виконано, функція «додати в кошик» не працюватиме.

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

Помилки API можуть бути різними, і тут ми розповімо вам докладніше про 5 найпопулярніших з них: 

Неправильний метод HTTP

Найпростішою, але поширеною помилкою API є неправильний метод HTTP. Часто проблема виникає через прогалини в документації. Одним із прикладів може бути надсилання запиту GET із зазначенням опції даних, але пропускаючи згадування параметра -X GET. У результаті він автоматично перетворюється на запит POST. Крім того, проблеми з методами HTTP можуть виникати під час перемикання інструментів API, оскільки деякі з них можуть використовувати один метод для створення тестових середовищ і їх модифікації, тоді як інші використовують різні способи для цих дій. Тому важливо ретельно перевіряти ці нюанси, а також послідовно підходити до написання власної документації. 

Використання неправильного протоколу

Іншою поширеною помилкою є розбіжності між протоколами https:// і http://. Деякі API можуть підтримувати лише один із протоколів, скажімо, http, тому вказівка ​​https:// у такому випадку призведе до некоректної обробки запиту. Навіть якщо обидва вони підтримуються, можуть виникнути проблеми з переспрямуванням на https://, коли ви вказуєте http://. Випадок також може статися, коли постачальники сторонніх API, які ви плануєте використовувати, вносять деякі зміни та не надсилають сповіщення про це. Тому краще час від часу перевіряти ці аспекти. Для створення власного API краще використовувати протокол https://. Щоб це стало можливим, необхідно встановити сертифікат SSLдо господаря. Деякий час тому сертифікати SSL були дещо дорогими, тому могли бути сумніви щодо цього, але з безкоштовними постачальниками, такими як Letsencrypt або Cloudflare, це стає простіше, ніж будь-коли.

Відсутність значущих повідомлень про помилки

Якщо ви коли-небудь стикалися з « неочікуваною помилкою API», ви знаєте, як це може дратувати. Зазвичай повідомлення про помилки мають полегшити розробникам усунення несправностей, вказуючи на точну причину помилки або принаймні на те, де її шукати. На жаль, такі неінформативні помилки можуть призвести до годин втраченого часу, збільшення часу, необхідного для вирішення помилки, і, як наслідок, спричинити більший сплеск негативних відгуків, які ви отримуєте, тому краще витратити трохи більше часу на опис потенціалу помилки та зробити повідомлення інформативними для тих, кому потрібно буде їх усунути. Хоча існує кілька десятків кодів помилок HTTP, не обов’язково використовувати їх усі, але збережіть стандартні коди помилок (200, 400 і 500) і розгляньте можливість включення підказок у повідомлення, щоб навіть у випадках, коли щось не працює,

Проблеми з авторизацією

Може здатися, що тут все зрозуміло, оскільки неправильна авторизація зазвичай передбачає неправильність імені користувача або пароля, але насправді навіть плутання «авторизації» з «автентифікацією» в заголовках викликає помилку. Це особливо актуально для використання протоколу OAuth 2. Крім того, синтаксис має значення, тому що деякі прості, але менш очевидні речі можуть викликати плутанину. У більшості випадків це маркер носія, пробіл у префіксі «Основний», якого не вистачає для повного додавання цього префікса, і втрата двокрапки в парі «ім’я користувача: пароль». Навіть якщо ім’я користувача використовується окремо в деяких API, для яких не потрібен пароль, вам все одно доведеться використовувати цю двокрапку.

Не вдалося вказати заголовки Content-Type і Accept

Деякі API толерантні до запитів, у яких заголовки не містять Content-Type або заголовок Accept, але відповідають дозволеному формату даних. Інші є більш скрупульозними і не дозволять запит через надання коду помилки 403 Permission Denied. На цьому етапі встановлюється взаємодія між клієнтом і сервером щодо очікуваного типу даних у запиті та відповіді. Ця перевірка заголовків реалізована для зниження ризиків порушення безпеки та загальних спроб злому, тому краще вказати ці заголовки, щоб уникнути проблем під час використання.

Підведення підсумків

Виконання тестування API разом з іншими типами тестування, включаючи регресію, димовий тест і, звичайно, модульне тестування під час спринтів розробки, допоможе швидше випускати ваше програмне забезпечення. Логіка цього проста: чим раніше буде помічена помилка, дефект або невідповідність бізнес-вимогам, тим легше їх виправити. І, як наслідок, надайте першокласний досвід своїм кінцевим користувачам, які зможуть насолоджуватися взаємодією з вашим програмним забезпеченням без неочікуваних помилок у процесі, таким чином приносячи більше прибутку вашому бізнесу.