Меню

Коди відповідей API відпочинку та типи запитів на відпочинок

  • Головна
  • Інший
  • Коди відповідей API відпочинку та типи запитів на відпочинок

rest api response codes

Спробуйте Наш Інструмент Для Усунення Проблем

У цьому посібнику ми дізнаємося про різні коди відповідей REST, типи запитів REST та деякі найкращі практики, яких слід дотримуватися. :

У попередньому підручнику REST API Architecture And Constraints ми дізналися про веб-сервіси, REST Architecture, POSTMAN тощо.

Ми можемо звернутися до першого підручника API REST для отримання додаткової інформації щодо цього.

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

Різні типи кодів відповідей та запитів на відпочинок

Що ви дізнаєтесь:

Коди відповідей API відпочинку

Ось декілька зразків кодів відповідей, які ми зазвичай бачимо під час тестування REST API через POSTMAN або будь-який клієнт REST API.

No1) Серія 100
Це тимчасові відповіді

  • 100 Продовжуйте
  • 101 Перемикання протоколів
  • 102 Обробка

No2) Серія 200
Клієнт приймає Запит, успішно обробляючись на сервері.

що таке контроль якості та забезпечення якості
  • 200 - Добре
  • 201 - Створено
  • 202 - Прийнято
  • 203 - Неавторитетна інформація
  • 204 - Без вмісту
  • 205 - Скинути вміст
  • 206 - Частковий зміст
  • 207 - Мульти-статус
  • 208 - Вже повідомлено
  • 226 - ІМ використано

# 3) Серія 300
Більшість кодів, пов’язаних із цією серією, призначені для перенаправлення URL-адрес.

  • 300 - кілька варіантів
  • 301 - Переміщений назавжди
  • 302 - Знайдено
  • 303 - Перевірте Інше
  • 304 - Не змінено
  • 305 - Використовуйте проксі
  • 306 - комутатор проксі
  • 307 - Тимчасова перенаправлення
  • 308 - Постійне перенаправлення

No4) Серія 400
Вони характерні для помилки на стороні клієнта.

  • 400 - Помилковий запит
  • 401 - Несанкціонований
  • 402 - Потрібна оплата
  • 403 Заборонено
  • 404 Не знайдено
  • 405 - метод не дозволений
  • 406 - Не прийнятно
  • 407 - Потрібна автентифікація проксі
  • 408 - Час очікування запиту
  • 409 - Конфлікт
  • 410 - Пропав
  • 411 - необхідна довжина
  • 412 - Помилка передумови
  • 413 - Занадто великий корисний вантаж
  • 414 - URI занадто довгий
  • 415 - Непідтримуваний тип носія
  • 416 - Дальність не задовольняє
  • 417 - очікування не вдалося
  • 418 - Я чайник
  • 421 - Запит з помилковим спрямуванням
  • 422 - Неопрацьована сутність
  • 423 - Заблоковано
  • 424 - Невдала залежність
  • 426 - Потрібне оновлення
  • 428 - Потрібна передумова
  • 429 - Забагато запитів
  • 431 - Занадто великі поля заголовка запиту
  • 451 - Недоступний з юридичних причин

№5) Серія 500
Вони характерні для помилки на стороні сервера.

  • 500 Внутрішня помилка сервера
  • 501 - Не реалізовано
  • 502 - Bad Gateway
  • 503 - Послуга недоступна
  • 504 - Час очікування шлюзу
  • 505 - Версія HTTP не підтримується
  • 506 - Варіант також веде переговори
  • 507 - Недостатньо місця для зберігання
  • 508 - Виявлено петлю
  • 510 - Не продовжено
  • 511 - Потрібна автентифікація мережі

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

Різні типи запитів на відпочинок

Тут ми обговоримо кожен метод REST API разом із колекціями.

МетодОпис
ЛІПДуже подібний до викладеного, але це більше схоже на незначну маніпуляцію з вмістом ресурсів
ОТРИМАТИОтримати рядок стану, тіло відповіді, заголовок тощо.
КЕРІВНИКТе саме, що і GET, але лише отримати рядок стану та розділ заголовка
ОпублікуватиВиконуйте запит, використовуючи корисне навантаження запиту, головним чином при створенні запису на сервері
ВСТАНОВИТИКорисно для маніпулювання / оновлення ресурсу за допомогою запиту на корисне навантаження
ВИДАЛИТИВидаляє інформацію, що стосується цільового ресурсу.
ВАРІАНТИОпишіть варіанти спілкування для цільового ресурсу

Примітка: Існує так багато методів, які ми можемо зробити за допомогою POSTMAN, але ми обговоримо лише наступні методи, використовуючи POSTMAN.

Для демонстрації ми використовуватимемо фіктивну URL-адресу http://jsonplaceholder.typicode.com . Ця URL-адреса дасть нам бажані відповіді, але створення та модифікація на сервері не відбуватиметься.

# 1) ОТРИМАТИ

Параметри запиту:
Метод: GET
URI запиту: http://jsonplaceholder.typicode.com/posts
Параметр запиту: id = 3;

Отримана відповідь:
Код стану відповіді: 200 OK

Орган відповіді :

Орган відповіді

# 2) ГОЛОВА

Параметри запиту:
Метод: ГОЛОВА
URI запиту: http://jsonplaceholder.typicode.com/posts

КЕРІВНИК

# 3) POST

Опублікувати

# 4) ПОСТАВИТИ

ВСТАНОВИТИ

ВИДАЛИТИ

# 5) ВАРІАНТИ

Параметри запиту:
Метод: ВАРІАНТИ
URI запиту: http://jsonplaceholder.typicode.com/
Заголовки: Content-type = Application / JSON

основні питання для співбесіди для тестувальників

ВАРІАНТИ

# 6) ЛІК

ЛІП

Найкращі практики під час перевірки REST API

# 1) CRUD-операції

Складається із мінімум 4 наданих методів і повинен працювати у веб-API.
ОТРИМАТИ, Опублікувати, ВСТАНОВИТИ І ВИДАЛИТИ.

# 2) Обробка помилок

Можливі підказки для споживачів API щодо помилки та причини її виникнення. Він також повинен надавати детальні повідомлення про помилки.

# 3) Версія API

Використовуйте в URL-адресі букву „v” для позначення версії API. Наприклад-

http://restapi.com/api/v3/passed/319

Додатковий параметр у кінці URL-адреси

http://restapi.com/api/user/invaiiduser?v=6.0

# 4) Фільтрування

Дозволяючи користувачеві вказати, виберіть потрібні дані, а не надавати їх усі одночасно.
/ контакт / sam? ім'я, вік, призначення, офіс
/ контакти? limit = 25 & offset = 20

# 5) Безпека

Мітка часу в кожному запиті та відповіді API. Використання access_token, щоб переконатися, що сторони довіри викликають API.

номер символу до int c ++

# 6) Аналітика

Наявність Analytics у вашому REST API дасть вам хороший уявлення про тестований API, особливо коли кількість отриманих записів дуже велика.

# 7) Документація

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

# 8) Структура URL-адреси

Структура URL-адреси повинна залишатися простою, а користувач повинен мати можливість легко читати над нею доменне ім’я.

Наприклад , https://api.testdomain.com.

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

Наприклад, для поштового клієнта:

ОТРИМАТИ: read / inbox / messages - Отримує список усіх повідомлень у папці 'Вхідні'
ОТРИМАТИ: read / inbox / messages / 10 - читає 10гоповідомлення у папці 'Вхідні'
ПОСТ: create / inbox / folders - Створіть нову папку в папці Вхідні
ВИДАЛИТИ: Видалити / спам / повідомлення - Видалити всі повідомлення в папці зі спамом
ВСТАНОВИТИ: папки / вхідні / підпапка - Оновіть інформацію, що стосується вкладеної папки в папці Вхідні.

Висновок

Багато організацій віддають перевагу впровадженню веб-API REST, оскільки він дуже простий у впровадженні, має менші стандарти та правила для дотримання, простий у доступі, легкий та зрозумілий. POSTMAN має свої переваги при використанні з RESTful API завдяки зручному для користувача інтерфейсу, простоті використання та тестування, швидшій швидкості відгуку та новій функції RUNNER.

У наступному навчальному посібнику з цієї серії підручників з API відпочинку ми автоматизуємо тестові кейси, які ми виконували вручну.

Рекомендована література

^