Меню

Кодове за отговор на API за почивка и типове заявки за почивка

  • Основен
  • Други
  • Кодове за отговор на API за почивка и типове заявки за почивка

rest api response codes

Опитайте Нашия Инструмент За Премахване На Проблемите

В този урок ще научим за различни кодове за отговор на REST, типове REST заявки и някои най-добри практики, които трябва да се следват :

В предишния урок, REST API Architecture And Constraints, научихме за уеб услугите, REST Architecture, POSTMAN и др.

Може да се обърнем към първия урок на REST API за повече информация относно това.

Всеки път, когато търсите която и да е дума или фраза в търсачката, търсачката изпраща заявката до уеб сървъра. Уеб сървърът връща трицифрен код за отговор, който показва състоянието на заявката.

Различни видове кодове за отговор и заявки за почивка

Какво ще научите:

Кодове за отговор на API за почивка

Ето някои примерни кодове за отговор, които обикновено ще виждаме, докато извършваме тестване на REST API през POSTMAN или над всеки клиент на REST API.

# 1) Серия 100
Това са временни отговори

  • 100 Продължете
  • 101 Превключване на протоколи
  • 102 Обработка

# 2) Серия 200
Клиентът приема заявката, като се обработва успешно на сървъра.

Въпроси и отговори за интервю за php за 1-годишен опит
  • 200 - Добре
  • 201 - Създаден
  • 202 - Прието
  • 203 - Неавторитетна информация
  • 204 - Няма съдържание
  • 205 - Нулиране на съдържанието
  • 206 - Частично съдържание
  • 207 - Multi-Status
  • 208 - Вече докладвано
  • 226 - Използва се IM

# 3) Серия 300
Повечето кодове, свързани с тази поредица, са за пренасочване на URL адреси.

  • 300 - Множество възможности за избор
  • 301 - Преместено за постоянно
  • 302 - Намерен
  • 303 - Проверете друго
  • 304 - Не е модифициран
  • 305 - Използвайте прокси
  • 306 - превключващ прокси
  • 307 - Временно пренасочване
  • 308 - Постоянно пренасочване

# 4) Серия 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, но само извличане на ред за състояние и заглавна секция
ПОСТИзпълнявайте заявка, като използвате полезен товар на заявката най-вече при създаване на запис на сървъра
СЛАГАМПолезно при манипулиране / актуализиране на ресурса с помощта на Request payload
ИЗТРИЙИзтрива информация, свързана с целевия ресурс.
НАСТРОИКИОпишете възможностите за комуникация за целевия ресурс

Забележка: Съществуват толкова много методи, които можем да направим с помощта на 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) ПОСТАВЕТЕ

СЛАГАМ

ИЗТРИЙ

ls команда в unix с примери

# 5) ОПЦИИ

Параметри на заявката:
Метод: ОПЦИИ
URI адрес на заявката: http://jsonplaceholder.typicode.com/
Заглавки: Content-type = Application / JSON

НАСТРОИКИ

# 6) КРЪПКА

КРЕПА

Най-добри практики при валидиране на REST API

# 1) CRUD операции

Състои се от минимум 4 предоставени метода и трябва да работи в уеб API.
ВЗЕМЕТЕ, ПОСТАВЕТЕ, ПОСТАВЕТЕ И ИЗТРИЕТЕ

# 2) Обработка на грешки

Възможни съвети за потребителите на API за грешката и защо е възникнала. Той също така трябва да предоставя подробни съобщения за грешки.

# 3) API версиране

Използвайте буквата „v“ в URL адреса, за да обозначите версията на 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 се извиква от доверителните страни.

спокойни уеб услуги тестване въпроси интервю

# 6) Анализ

Наличието на Анализ във вашия REST API ще ви даде добра представа за тествания API, особено когато броят на извлечените записи е много голям.

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

Трябва да се предостави подходяща документация, така че потребителите на API да могат да я използват и да консумират услугите ефективно.

# 8) URL структура

Структурата на URL трябва да остане проста и потребителят трябва да може лесно да чете името на домейна върху него.

Например , https://api.testdomain.com.

Операциите, които трябва да се извършват през API за почивка, също трябва да бъдат много лесни за разбиране и изпълнение.

Например за имейл клиент:

ВЗЕМЕТЕ: read / inbox / messages - извлича списъка с всички съобщения под входящата поща
ВЗЕМЕТЕ: read / inbox / messages / 10 - чете 10тисъобщение във входящата поща
ПОЩА: create / inbox / folders - Създайте нова папка под inbox
ИЗТРИЙ: Изтриване / спам / съобщения - Изтрийте всички съобщения в папката за спам
СЛАГАМ: папки / пощенска кутия / подпапка - Актуализирайте информацията, свързана с подпапката под входящата поща.

Заключение

Много организации предпочитат да внедрят REST Web API, тъй като той е много лесен за изпълнение, има по-ниски стандарти и правила за спазване, лесен за достъп, лек и лесен за разбиране. POSTMAN има своите предимства, когато се използва с RESTful API, благодарение на потребителския си потребителски интерфейс, лекота на използване и тест, по-бърз процент на реакция и нова функция RUNNER.

В следващия урок от тази серия на Rest API Tutorial ще автоматизираме тестовите случаи, които сме изпълнили ръчно.

Препоръчително четене

^