Пиша този блог, за да споделя знанията си за API тестване. Този блог ще бъде разделен на следните части:
- API и основна дискусия за него
- API тестване с помощта на Postman
Част 2 от този блог ще бъде за това как да автоматизирате тестване на API и базирано на данни тестване с помощта на пощальон.
I. API и основна дискусия за него
и. Какво е API?
Пълната форма на API е интерфейс за програмиране на приложения. Той осигурява начин, по който софтуерните системи могат да комуникират една с друга. Например, ако имате WhatsApp, може да сте виждали много фирми да се свързват с вас чрез техните бизнес акаунти в WhatsApp, те използват WhatsApp API под капака.
ii. Какво е API тестване?
Като всеки софтуерен продукт API също изисква тестване. API се използва от разработчиците за внедряване на функционалност в софтуера, която не е директно достъпна за крайния потребител за взаимодействие. Например, когато влезете в който и да е уебсайт за онлайн пазаруване и преминете към страницата с продуктов списък, ще бъде извикан API, за да изброи всички налични артикули на страницата, които можете да видите в мрежовия раздел на вашия уеб браузър.
iii. Какви са различните API методи и тяхното значение?
Тук ще се опитам да споделя какви са различните налични API методи и ще взема примерна система за управление на записи на служители.
а. GET — Тези HTTP методи се използват за извличане на информация за ресурси, само че не променят нищо по никакъв начин. Те променят/актуализират състоянието на ресурса на сървъра. Например в система за управление на записи на служители можем да видим подробностите за всички служители на една страница, там ще използва метода GET API.
b. POST— Тези HTTP методи се използват за създаване на нов ресурс на сървъра. Например в системата за управление на записи на служители, когато нов служител се присъедини към организацията, администраторът ще въведе всички подробности за този служител в системата, тогава това ще бъде повикване, защото ще създаде нов запис в системата, който не е съществувал по-рано
° С. PUT – Тези HTTP методи се използват за актуализиране на съществуващ ресурс. Например в системата за управление на записи на служители, ако искаме да актуализираме някаква информация за съществуващ служител, тогава администраторът ще отиде до информацията за конкретния служител и ще актуализира някаква информация, след което това ще бъде PUT извикване на API .
д. ИЗТРИВАНЕ— Тези HTTP методи се използват за изтриване на ресурса. Например в системата за управление на записи на служители, ако премахнем служителя от системата, когато служителят е напуснал организацията, тогава ще премахнем подробностите за служителя от системата, което ще бъде обаждане за изтриване, но имайте предвид, че може да не изтрием напълно информацията, която може да запази някои метаданни за същото.
д. PATCH — Този HTTP метод се използва за частично актуализиране на ресурса. Ако искате да актуализирате изцяло информацията на съществуващ ресурс, тогава трябва да използвате PUT, в противен случай трябва да използвате PATCH.
iv. От какво се състои извикването на API?
RESTful API изискват заявките да съдържат следното:
а. Уникален идентификатор на ресурс (URI) —Това е крайната точка на API, която е проектирана с някаква цел
b. HTTP метод — Може да бъде един от HTTP методите като GET, PUT, POST, PATCH ИЛИ DELETE
° С. HTTP заглавки— Ще има информация като токен за удостоверяване.
d.Основни данни — Основният текст на заявката е данни, изпратени от клиента към вашия API. Тялото на отговора е данните, които вашият API изпраща на клиента. Вашият API почти винаги трябва да изпрати тяло на отговор. Но не е задължително клиентите да изпращат тела на заявки през цялото време.
Моля, намерете изображението по-долу за справка:
с. Какви са различните кодове за състояние на HTTP отговор и какво е значението им?
Кодовете за състояние на HTTP отговор ни дават информация за това дали конкретна HTTP заявка е била завършена успешно или не. Моля, намерете групирането по-долу:
а. 1XX — Информационни отговори
b.2XX— Успешни отговори
° С. 3XX— Съобщение за пренасочване
д. 4XX— Отговори при грешка на клиента
д. 5XX— Отговори за грешка на сървъра
Можете да намерите повече информация тук. Повечето от кодовете за общо състояние, които може да видите, са изброени по-долу:
a. 200 OK
Заявката е успешна. Резултатното значение на „успех“ зависи от HTTP метода:
GET: Ресурсът е извлечен и предаден в тялото на съобщението.HEAD: Представителните заглавки са включени в отговора без никакъв текст на съобщението.PUTилиPOST: Ресурсът, описващ резултата от действието, се предава в тялото на съобщението.TRACE: Основният текст на съобщението съдържа съобщението за заявка, получено от сървъра.
b. 201 Създаден
Заявката е успешна и в резултат на това е създаден нов ресурс. Това обикновено е отговорът, изпратен след POST заявки или някои PUT заявки.
° С. 400 Лоша заявка
Сървърът не може или няма да обработи заявката поради нещо, което се възприема като клиентска грешка (напр. неправилен синтаксис на заявка, невалидно рамкиране на съобщение на заявка или измамно маршрутизиране на заявка).
д. 401 Неупълномощен
Въпреки че HTTP стандартът уточнява „неоторизиран“, семантично този отговор означава „неупълномощен“. Това означава, че клиентът трябва да се удостовери, за да получи искания отговор.
д. 403 Забранено
Клиентът няма права за достъп до съдържанието; това означава, че е неупълномощено, така че сървърът отказва да предостави искания ресурс. За разлика от 401 Unauthorized, самоличността на клиента е известна на сървъра.
f. 404 Не е намерен
Сървърът не може да намери искания ресурс. В браузъра това означава, че URL адресът не е разпознат. В API това може също да означава, че крайната точка е валидна, но самият ресурс не съществува. Сървърите могат също така да изпратят този отговор вместо 403 Forbidden, за да скрият съществуването на ресурс от неоторизиран клиент. Този код за отговор е може би най-известният поради честото му появяване в мрежата.
ж. 405 Неразрешен метод
Методът на заявката е известен на сървъра, но не се поддържа от целевия ресурс. Например API може да не позволява извикване на DELETE за премахване на ресурс.
ч. 500 вътрешна грешка на сървъра
Сървърът е изпаднал в ситуация, с която не знае как да се справи.
аз 501 не е внедрено
Методът на заявка не се поддържа от сървъра и не може да бъде обработен. Единствените методи, които сървърите трябва да поддържат (и следователно не трябва да връщат този код), са GET и HEAD.
й. 502 Лош шлюз
Този отговор за грешка означава, че сървърът, докато работи като шлюз за получаване на отговор, необходим за обработка на заявката, е получил невалиден отговор.
к. Услугата 503 не е налична
Сървърът не е готов да обработи заявката. Често срещаните причини са сървър, който не работи за поддръжка или е претоварен. Имайте предвид, че заедно с този отговор трябва да бъде изпратена удобна за потребителя страница, обясняваща проблема. Този отговор трябва да се използва за временни условия и Retry-After HTTP хедърът трябва, ако е възможно, да съдържа очакваното време преди възстановяването на услугата. Уеб администраторът трябва също да се погрижи за заглавките, свързани с кеширането, които се изпращат заедно с този отговор, тъй като тези временни отговори на условия обикновено не трябва да се кешират.
л. 504 Gateway Timeout
Този отговор за грешка се дава, когато сървърът действа като шлюз и не може да получи отговор навреме.
м. 505 HTTP версия не се поддържа
HTTP версията, използвана в заявката, не се поддържа от сървъра.
II. API тестване с помощта на Postman
Сега да видим как можем да направим тестването в Postman
а. ПОЛУЧЕТЕ обаждане
- Отворете пощальона
- Кликнете върху опцията Файл ›Импортиране
- Залепете долната къдрица
curl --location 'https://reqres.in/api/users?page=2'
4. Щракнете върху бутона Изпрати, след което ще получитекод за състояние 200 OK.
b. POST обаждане
Същите стъпки за пощальона, както споменатите за GET повикването, но с извивката по-долу
curl --location 'https://reqres.in/api/users' \
--header 'authority: reqres.in' \
--header 'accept: */*' \
--header 'accept-language: en-US,en;q=0.9' \
--header 'content-type: application/json' \
--header 'cookie: _ga=GA1.2.1623896579.1680277266; _gid=GA1.2.863968265.1680277266; __stripe_mid=a96e5fcc-55ad-477f-a134-c0b75d205a3143e066; __stripe_sid=44917c41-9ea0-4d9e-9fea-35abafd3f7c6f3d96d' \
--header 'dnt: 1' \
--header 'origin: https://reqres.in' \
--header 'referer: https://reqres.in/' \
--header 'sec-ch-ua: "Google Chrome";v="111", "Not(A:Brand";v="8", "Chromium";v="111"' \
--header 'sec-ch-ua-mobile: ?0' \
--header 'sec-ch-ua-platform: "macOS"' \
--header 'sec-fetch-dest: empty' \
--header 'sec-fetch-mode: cors' \
--header 'sec-fetch-site: same-origin' \
--header 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36' \
--data '{
"name": "morpheus",
"job": "leader"
}'
° С. PUT Call
Същите стъпки за пощальона, както споменатите за GET повикването, но с извивката по-долу
curl --location --request PUT 'https://reqres.in/api/users/2' \
--header 'authority: reqres.in' \
--header 'accept: */*' \
--header 'accept-language: en-US,en;q=0.9' \
--header 'content-type: application/json' \
--header 'cookie: _ga=GA1.2.1623896579.1680277266; _gid=GA1.2.863968265.1680277266; __stripe_mid=a96e5fcc-55ad-477f-a134-c0b75d205a3143e066; __stripe_sid=44917c41-9ea0-4d9e-9fea-35abafd3f7c6f3d96d' \
--header 'dnt: 1' \
--header 'origin: https://reqres.in' \
--header 'referer: https://reqres.in/' \
--header 'sec-ch-ua: "Google Chrome";v="111", "Not(A:Brand";v="8", "Chromium";v="111"' \
--header 'sec-ch-ua-mobile: ?0' \
--header 'sec-ch-ua-platform: "macOS"' \
--header 'sec-fetch-dest: empty' \
--header 'sec-fetch-mode: cors' \
--header 'sec-fetch-site: same-origin' \
--header 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36' \
--data '{
"name": "morpheus",
"job": "zion resident"
}'
д. PATCH повикване
Същите стъпки за пощальона, както споменатите за GET повикването, но с извивката по-долу
curl --location --request PATCH 'https://reqres.in/api/users/2' \
--header 'authority: reqres.in' \
--header 'accept: */*' \
--header 'accept-language: en-US,en;q=0.9' \
--header 'content-type: application/json' \
--header 'cookie: _ga=GA1.2.1623896579.1680277266; _gid=GA1.2.863968265.1680277266; __stripe_mid=a96e5fcc-55ad-477f-a134-c0b75d205a3143e066' \
--header 'dnt: 1' \
--header 'origin: https://reqres.in' \
--header 'referer: https://reqres.in/' \
--header 'sec-ch-ua: "Google Chrome";v="111", "Not(A:Brand";v="8", "Chromium";v="111"' \
--header 'sec-ch-ua-mobile: ?0' \
--header 'sec-ch-ua-platform: "macOS"' \
--header 'sec-fetch-dest: empty' \
--header 'sec-fetch-mode: cors' \
--header 'sec-fetch-site: same-origin' \
--header 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36' \
--data '{"name":"morpheus","job":"zion resident"}'
д. ИЗТРИВАНЕ на повикване
Същите стъпки за пощальона, както споменатите за повикването GET, но с извивката по-долу
curl -X DELETE \ https://restful-booker.herokuapp.com/booking/1 \ -H 'Content-Type: application/json' \ -H 'Cookie: token=abc123'
Има възможност за извършване на управлявано от данни тестване с помощта на Postman, което ще разгледаме във втората част на този блог. Това е всичко, което хората ще ви видят в следващия блог. Дотогава приятно тестване 😃!!
Препратки:
iv. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
срещу https://www.sitepoint.com/
