Zamonaviy veb-loyihalarning deyarli barchasi API'lar ustiga quriladi. Frontend serverdan ma'lumot oladi, mobil ilova bulutga ulanadi, to'lov tizimlari bir-biri bilan so'rovlar almashadi. Bularning hammasi to'g'ri ishlayotganiga ishonch hosil qilish uchun har bir so'rovni qo'lda brauzerda tekshirish mumkin emas. Aynan shu yerda Postman maydonga chiqadi. Postman API'larni sinash, hujjatlash va avtomatlashtirish uchun mo'ljallangan eng mashhur vositadir va u oddiy GET so'rovini yuborishdan tortib butun bir test to'plamini CI quvuriga ulashgacha bo'lgan ishlarni qamrab oladi.
Ushbu maqolada biz Postman'ni noldan o'rganamiz. Avval interfeys va asosiy so'rovlar bilan tanishamiz, so'ngra kolleksiya va muhitlardan foydalanib ishni tartibga solamiz. Keyin JavaScript test skriptlari yozib, API javoblarini avtomatik tekshirishni ko'ramiz va nihoyat Collection Runner hamda Newman yordamida butun test to'plamini avtomatlashtirib, uni doimiy integratsiya jarayoniga qo'shamiz. Maqola dasturchilar va testerlar uchun bir xil darajada foydali.
Postman nima va u nima uchun kerak
Postman โ bu HTTP so'rovlarini qurish va yuborish uchun grafik muhit. Brauzer faqat GET so'rovlarini qulay yuborsa, Postman POST, PUT, DELETE, PATCH kabi barcha metodlarni qo'llab-quvvatlaydi, header'lar va body'ni aniq sozlash imkonini beradi hamda javobni chiroyli formatda ko'rsatadi. Eng muhimi, Postman har bir so'rovni saqlab, ularni kolleksiyalarga guruhlab, jamoa bilan ulashish imkonini beradi. Bu API ustida ishlayotgan jamoa uchun yagona haqiqat manbai bo'lib xizmat qiladi.
Postman'ning kuchi shundaki, u shunchaki so'rov yuboruvchi emas. U sizga API hujjatlarini avtomatik yaratish, soxta server (mock server) ishga tushirish, monitoring o'rnatish va eng asosiysi avtomatik testlar yozish imkonini beradi. Shu sababli ko'p jamoalarda Postman API'ning butun hayot tsiklini boshqaradigan markaziy vositaga aylanadi.
Birinchi so'rov: GET va POST
Postman'ni ochganingizdan so'ng yangi so'rov yaratasiz, metodni tanlaysiz va URL'ni kiritasiz. Oddiy GET so'rovi ma'lumot olib kelish uchun ishlatiladi. Masalan, foydalanuvchilar ro'yxatini olish uchun siz quyidagicha so'rov yuborasiz va Postman javobni JSON ko'rinishida ko'rsatadi:
GET https://api.example.com/v1/users
Accept: application/json
# Javob:
{
"data": [
{ "id": 1, "name": "Ali" },
{ "id": 2, "name": "Vali" }
]
}POST so'rovi esa server'ga yangi ma'lumot yuborish uchun ishlatiladi. Bunda siz Body bo'limiga o'tib, raw va JSON formatini tanlaysiz hamda yuboriladigan ma'lumotni yozasiz. Authentication kerak bo'lsa, Authorization bo'limida Bearer Token yoki API Key turini tanlaysiz. Quyidagi misol yangi foydalanuvchi yaratishni ko'rsatadi:
POST https://api.example.com/v1/users
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiI...
{
"name": "Sardor",
"email": "sardor@example.com"
}Kolleksiya va muhit (environment)
Bir nechta so'rov bilan ishlay boshlaganingizda ularni tartibga solish zarurati tug'iladi. Kolleksiya โ bu o'zaro bog'liq so'rovlar to'plami, masalan "Foydalanuvchilar API" yoki "To'lov API". Kolleksiyalar so'rovlarni papkalarga ajratish, ularga tavsif yozish va butun to'plamni bir marta ishga tushirish imkonini beradi. Bu API'ni tartibli holatda saqlashning asosiy usuli.
Muhit (environment) esa o'zgaruvchilar to'plami bo'lib, u bir xil kolleksiyani turli sharoitlarda ishlatish imkonini beradi. Masalan, sizda "dev", "staging" va "production" muhitlari bo'lishi mumkin va har birida URL hamda token boshqacha. So'rovlarda qattiq kodlangan qiymatlar o'rniga {{base_url}} kabi o'zgaruvchilardan foydalanasiz va muhitni almashtirgan zahoti barcha so'rovlar yangi qiymatlar bilan ishlay boshlaydi:
// Muhit o'zgaruvchilari:
base_url = https://api.example.com/v1
token = eyJhbGciOiJIUzI1NiI...
// So'rovda ishlatish:
GET {{base_url}}/users
Authorization: Bearer {{token}}Test yozish: JavaScript skriptlari
Postman'ning eng kuchli tomoni har bir so'rovga test skriptlari biriktirish imkoniyatidir. Bu skriptlar JavaScript'da yoziladi va so'rovdan javob kelgandan keyin avtomatik ishga tushadi. Test skriptlari javobning to'g'riligini tekshiradi: status kodi kutilganga mosmi, javob qancha vaqtda keldi, body ichida kerakli maydonlar bormi. Pastdagi misolda status kodi va javob tuzilishini tekshiruvchi oddiy testlar ko'rsatilgan:
pm.test("Status kodi 200 bo'lsin", function () {
pm.response.to.have.status(200);
});
pm.test("Javob 500ms dan tez kelsin", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
pm.test("Javobda data massivi bor", function () {
const json = pm.response.json();
pm.expect(json.data).to.be.an('array');
pm.expect(json.data.length).to.be.above(0);
});Test skriptlari nafaqat tekshiradi, balki keyingi so'rovlar uchun o'zgaruvchilarni saqlay oladi. Masalan, login so'rovidan kelgan token'ni o'zgaruvchiga saqlab, keyingi so'rovlarda undan foydalanish juda keng tarqalgan amaliyot. Bu zanjirli (chained) so'rovlar tuzish imkonini beradi:
// Login javobidan token'ni olib saqlash:
const json = pm.response.json();
pm.environment.set("token", json.access_token);
// Endi keyingi so'rovlarda {{token}} avtomatik ishlaydiAvtomatlashtirish: Collection Runner va Newman
Bir nechta so'rov va ularning testlari tayyor bo'lgach, ularni birma-bir qo'lda ishga tushirish o'rniga butun kolleksiyani avtomatik ishga tushirish mumkin. Collection Runner โ bu Postman ichidagi vosita bo'lib, u kolleksiyadagi barcha so'rovlarni ketma-ket yuboradi va har bir testning natijasini ko'rsatadi. Siz hatto CSV fayldan ma'lumot olib, bitta so'rovni turli kiruvchi qiymatlar bilan ko'p marta ishga tushirishingiz mumkin.
Haqiqiy avtomatlashtirish esa Newman bilan boshlanadi. Newman โ bu Postman kolleksiyalarini buyruqlar qatorida (command line) ishga tushiradigan vosita. U sizga testlarni har bir kod o'zgarishidan keyin avtomatik ishga tushirish, ya'ni doimiy integratsiya (CI/CD) quvuriga ulash imkonini beradi. Quyidagi misol Newman'ni o'rnatish va kolleksiyani ishga tushirishni ko'rsatadi:
# Newman'ni o'rnatish:
npm install -g newman
# Kolleksiyani muhit bilan ishga tushirish:
newman run users-api.postman_collection.json \
-e production.postman_environment.json \
--reporters cli,jsonBu buyruqni GitHub Actions yoki GitLab CI ichiga qo'yib, har bir push'dan keyin API testlari avtomatik ishlashini ta'minlash mumkin. Agar biror test muvaffaqiyatsiz tugasa, quvur to'xtaydi va jamoa darhol xabardor bo'ladi. Bu API regressiyalarini ishlab chiqarishga chiqishdan oldin tutib qolishning eng ishonchli usuli.
Mock server va real ish jarayoni
Ba'zan frontend jamoasi API tayyor bo'lishini kutmasdan ishni boshlashi kerak. Postman'ning mock server imkoniyati aynan shu vaziyat uchun. Siz kolleksiyaga kutilayotgan javoblarni namuna sifatida saqlaysiz va Postman sizga real API'ni taqlid qiluvchi URL beradi. Frontend bu soxta server bilan ishlab tura oladi, keyin esa real API tayyor bo'lganda oddiygina URL'ni almashtirasiz.
Real ish jarayoni odatda quyidagicha kechadi: dasturchi yangi endpoint yozadi, uni Postman'da qo'lda sinaydi, so'ngra unga test skriptlari qo'shib kolleksiyaga saqlaydi. Tester bu kolleksiyani kengaytirib, chegaraviy holatlarni qoplaydi. Nihoyat butun kolleksiya Newman orqali CI quvuriga ulanadi va har bir relizda avtomatik ishlaydi. Shunday qilib Postman bitta vositada API'ning butun hayotini โ birinchi so'rovdan to avtomatlashtirilgan regressiya testlarigacha โ boshqarish imkonini beradi. Bu nafaqat vaqtni tejaydi, balki API sifatini barqaror saqlaydi.