HTTP metodlari va status kodlari: GET, POST, 200, 404, 500

Qisqacha: HTTP metodi — mijoz nima qilmoqchi: GET — olish, POST — yangi yaratish, PUT/PATCH — yangilash, DELETE — o'chirish. Status kodi — server javobida nima bo'lganini bildiradigan uch xonali son: 2xx — muvaffaqiyat, 3xx — boshqa joyga yo'naltirish, 4xx — mijoz xatosi, 5xx — server xatosi.

Bu darsda

• Beshta asosiy metodni va ular qachon ishlatilishini bilasiz.
• PUT va PATCH farqini haqiqiy javob misolida ko'rasiz.
• "Xavfsiz" va "idempotent" metod nima ekanini tushunasiz va nega to'lov tugmasi ehtiyotkorlik talab qilishini bilasiz.
• Status kodlarining 5 oilasini va eng ko'p uchraydigan 15 ga yaqin kodni taniysiz.
• curl bilan istalgan metodda so'rov yuborib, status kodini tekshira olasiz.

Oldin bilishingiz kerak: Client–server modeli va HTTP xabari, URL anatomiyasi.

1. Nega bu kerak?

Malika onlayn do'konda "To'lash" tugmasini bosdi. Internet sekin, sahifa qotib qoldi. U tugmani yana bosdi. Kartasidan pul bir marta yechilishi kerakmi yoki ikki marta?

Boshqa vaziyat. Jasur saytni ochdi va ekranda 404 ko'rdi. Do'sti boshqa saytda 500 ko'rdi. Ikkalasi ham "sayt ishlamayapti" deydi. Lekin birinchisida havola noto'g'ri, ikkinchisida esa serverdagi dastur buzilgan — butunlay boshqa muammolar, boshqa odam tuzatadi.

Oldingi darsda HTTP xabarining tuzilishini ko'rdik: so'rov qatorida metod, javobning holat qatorida status kodi turadi. Bugun ikkalasining ichiga kiramiz. Bu so'zlarni frontend ham, backend ham har kuni ishlatadi.

2. HTTP metodlari

2.1 Metod — so'rovdagi fe'l

HTTP metodi (method) — so'rov bilan resursga nima qilmoqchi ekanimizni bildiradigan so'z. U so'rov qatorining boshida turadi: GET /menyu HTTP/1.1. Metod — gapdagi fe'l, URL esa — "nimaga".

Misol uchun choyxonaning buyurtmalar tizimini olaylik. Resurs — buyurtmalar, URL — /buyurtmalar. Har qanday ma'lumot bilan to'rtta asosiy ish qilinadi: yaratish, o'qish, yangilash, o'chirish. Har biriga o'z metodi bor:

Endi har birini haqiqiy server bilan sinab ko'ramiz. Oldingi darsdagi jsonplaceholder.typicode.com mashq serveridan foydalanamiz: u har qanday so'rovga haqiqiy javob beradi, lekin hech narsani saqlamaydi — xohlagancha sinash mumkin.

2.2 curl bilan metod tanlash

curl odatda GET yuboradi. Boshqa metod uchun uchta flag kerak bo'ladi:

• -X PATCH — metodni tanlash (X — "request", so'rov turi).
• -H "Content-Type: application/json" — sarlavha qo'shish (H — header).
• -d '{"title":"Yangi"}' — body yuborish (d — data).

Quyidagi buyruqlar Git Bash uchun yozilgan. Windows PowerShell'da -d ichidagi qo'shtirnoqlar yo'qolib qoladi — bu haqda "Ko'p uchraydigan xatolar" bo'limida.

2.3 GET — olish

GET — resursni o'qish. Serverdagi hech narsani o'zgartirmaydi. Brauzerda manzil yozib Enter bosganingizda, havolani bosganingizda — har safar GET ketadi. Body yo'q; qo'shimcha ma'lumot kerak bo'lsa, query'ga yoziladi.

curl -i https://jsonplaceholder.typicode.com/posts/1

Javob HTTP/1.1 200 OK va body'da 1-postning JSON'i bo'ladi.

2.4 POST — yangi yaratish

POST — serverda yangi narsa yaratish: ro'yxatdan o'tish, buyurtma berish, izoh qoldirish. Yangi narsaning ma'lumoti body'da ketadi.

curl -i -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"Salom","userId":1}'

(Qator oxiridagi \ — "buyruq keyingi qatorda davom etadi" degani. Uzun buyruq shunday o'qishga qulay bo'ladi. Hammasini bir qatorga yozsangiz ham ishlaydi.) Haqiqiy javob (qisqartirilgan):

HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8

{
  "title": "Salom",
  "userId": 1,
  "id": 101
}

201 Created — "yaratildi". Server yangi postga o'zi id berdi — 101. Yangi resursga raqamni mijoz emas, server beradi. Shuning uchun URL'da raqam yo'q: /posts, /posts/101 emas.

2.5 PUT va PATCH — yangilash

Ikkalasi ham yangilaydi, lekin farqi katta:

• PUT — resursni butunlay almashtiradi. Siz yuborgan narsa eskisining o'rniga to'liq yoziladi.
• PATCH — resursni qisman o'zgartiradi. Faqat siz yuborgan maydonlar yangilanadi, qolganlari joyida qoladi.

Buni o'z ko'zimiz bilan ko'ramiz. 1-postda to'rtta maydon bor: userId, id, title, body. Ikkala metod bilan ham faqat title ni yuboramiz.

PATCH bilan:

curl -X PATCH https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"title":"Yangi"}'

{
  "userId": 1,
  "id": 1,
  "title": "Yangi",
  "body": "quia et suscipit\nsuscipit recusandae ..."
}

PUT bilan (xuddi o'sha body):

curl -X PUT https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"title":"Yangi"}'

{
  "title": "Yangi",
  "id": 1
}

(Ikkalasi ham haqiqiy javob; body matni qisqartirildi.) PATCH faqat title ni o'zgartirdi — userId va body qoldi. PUT esa butun postni siz yuborgan narsa bilan almashtirdi — userId va body yo'qoldi.

O'xshatish: PATCH — kiyimdagi teshikka yamoq solish. PUT — eski kiyimni tashlab, yangisini kiyish. Shuning uchun PUT bilan hamma maydonni to'liq yuborish kerak.

2.6 DELETE — o'chirish

DELETE — resursni o'chirish. Odatda body kerak emas: nimani o'chirish kerakligi URL'da.

curl -i -X DELETE https://jsonplaceholder.typicode.com/posts/1

Javob: HTTP/1.1 200 OK. Ko'p serverlar o'chirgandan keyin 204 No Content ham qaytaradi — "bajarildi, qaytaradigan narsa yo'q".

2.7 HEAD va OPTIONS

Yana ikki metodni tanib qo'ying:

• HEAD — xuddi GET, lekin server faqat sarlavhalarni qaytaradi, body'siz. Fayl bor-yo'qligini yoki hajmini bilish uchun qulay. curl -I (katta I) aynan HEAD yuboradi.
• OPTIONS — "bu manzilda qaysi metodlar ruxsat etilgan?" degan savol. Brauzer uni ba'zan o'zi yuboradi. Buni Same-Origin darsida ko'ramiz.

Tekshirib ko'ring: Foydalanuvchi profilida ism, telefon va manzil bor. Faqat telefon raqamini yangilash kerak. Qaysi metod qulayroq va nega?

3. Xavfsiz va idempotent metodlar

3.1 Xavfsiz metodlar

Xavfsiz metod (safe method) — serverdagi ma'lumotni o'zgartirmaydigan metod. Bular: GET, HEAD, OPTIONS. Ularni necha marta yuborsangiz ham, serverda hech narsa o'zgarmaydi.

Bu va'da juda muhim. Brauzerlar, qidiruv tizimlari va Telegram havola oldindan ko'rinishini (preview) yasash uchun sahifalarni o'zi ochib ko'radi — GET bilan. Agar GET biror narsani o'chirsa, robot havolalarni aylanib chiqib, ma'lumotlaringizni yo'q qilishi mumkin edi.

3.2 Idempotent metodlar

Idempotent (idempotent) — bir marta yoki ko'p marta bajarilishidan qat'i nazar, serverni bir xil holatda qoldiradigan amal.

O'xshatish: liftdagi "5" tugmasi. Bir marta bossangiz ham, o'n marta bossangiz ham, lift baribir 5-qavatga boradi. Matematikada ham shunday amal bor: sonni 1 ga ko'paytirish. 5 × 1 = 5, 5 × 1 × 1 × 1 = 5 — necha marta ko'paytirsangiz ham natija o'zgarmaydi.

Metodlarni tekshirib chiqamiz:

• GET /buyurtmalar/15 — 10 marta o'qisangiz ham, buyurtma o'zgarmaydi. Idempotent.
• PUT /buyurtmalar/15 — "15-buyurtma endi shunday bo'lsin". 10 marta yuborsangiz ham natija bitta. Idempotent.
• DELETE /buyurtmalar/15 — birinchi marta o'chiradi. Keyingi safarlar ham 15-buyurtma o'chgan holda qoladi. Idempotent. (Ikkinchi javob 404 bo'lishi mumkin — lekin idempotentlik status kodi haqida emas, serverdagi holat haqida.)
• POST /buyurtmalar — har safar yangi buyurtma yaratadi. 3 marta yuborilsa — 3 ta buyurtma. Idempotent emas.
• PATCH — kafolatlanmagan. "Narxni 5 000 so'm qil" — idempotent, "narxga 1 000 so'm qo'sh" — yo'q.

3.3 Malikaning to'lovi

Endi dars boshidagi savolga javob beramiz. To'lov — yangi narsa yaratish, ya'ni POST. POST idempotent emas. Agar hech qanday himoya bo'lmasa, ikkinchi bosish ikkinchi to'lovni yaratadi.

Shuning uchun dasturchilar ikki narsa qiladi. Birinchisi — tugma bosilgandan keyin uni o'chirib qo'yish (frontend'da). Ikkinchisi — har bir to'lovga noyob raqam berish: server "bu raqamli to'lovni allaqachon oldim" deb takrorni rad etadi. Click, Payme kabi to'lov tizimlari bilan ishlaganda aynan shunday raqamlar bilan ishlaysiz.

Tekshirib ko'ring: Internet uzilib, brauzer so'rov yetib bordimi-yo'qmi bilmay qoldi. Qaysi so'rovni avtomatik qayta yuborish xavfsiz: GET /mahsulotlar mi yoki POST /buyurtmalar mi?

4. Status kodlari

4.1 Beshta oila

Status kodi (status code) — javobning birinchi qatoridagi uch xonali son. U so'rov bilan nima bo'lganini aytadi. Eng muhimi — birinchi raqam: u kodning qaysi oilaga tegishli ekanini bildiradi.

Notanish kodni ko'rsangiz ham, birinchi raqamiga qarab ma'nosini taxmin qilasiz. Masalan, 418 — biror mijoz xatosi, 507 — biror server muammosi. 1xx kodlarni amalda deyarli ko'rmaysiz, ular HTTP'ning ichki ishida qoladi.

curl bilan faqat status kodini ko'rish uchun -w (write out — "oxirida yozib ber") flagi qulay:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com

200

-s — jim ishlash, -o /dev/null — body'ni tashlab yuborish, %{http_code} — status kodi. PowerShell'da /dev/null o'rniga NUL yozing.

4.2 2xx — muvaffaqiyat

• 200 OK — "hammasi joyida". Eng ko'p uchraydigan javob.
• 201 Created — "yangi resurs yaratildi". Odatda POST dan keyin — yuqorida ko'rdingiz.
• 204 No Content — "bajarildi, lekin body yo'q". Masalan, DELETE dan keyin.

4.3 3xx — yo'naltirish

• 301 Moved Permanently — "resurs doimiy ravishda yangi manzilga ko'chdi". Yangi manzil Location sarlavhasida bo'ladi.
• 302 Found — "vaqtincha boshqa manzilda". Masalan, login qilmagan foydalanuvchini kirish sahifasiga yuborish.
• 304 Not Modified — "siz keshda saqlagan nusxa hali yangi, qayta yuklamang". Trafik va vaqtni tejaydi.

http://github.com ni https siz ochsak, haqiqiy javob:

curl -I http://github.com

HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://github.com/

Server aytyapti: "Bu manzil doimiy ko'chdi, https://github.com/ ga boring." Brauzer buni o'zi bajaradi — siz sezmaysiz ham. curl esa faqat -L flagi bilan yo'naltirishga ergashadi.

304 ni ham ko'rish mumkin. Brauzer "shu sanadan keyin o'zgargan bo'lsa bering" deb so'raydi (sana — oldingi javobdagi last-modified sarlavhasidan):

curl -I https://example.com \
  -H "If-Modified-Since: Sat, 26 Sep 2026 09:10:30 GMT"

HTTP/1.1 304 Not Modified

Sahifa o'zgarmagan — server body'ni qayta yubormadi. Sizda bu sana boshqa bo'lishi mumkin. Keshni sarlavhalar darsida batafsil ko'ramiz.

Tekshirib ko'ring: Kompaniya saytini eski-nom.example dan yangi-nom.example ga butunlay ko'chirdi. Eski manzildagi so'rovlarga qaysi kod qaytarish kerak: 301 mi yoki 302 mi?

4.4 4xx — mijoz xatosi

• 400 Bad Request — "so'rov noto'g'ri tuzilgan". Masalan, body'dagi JSON buzuq yoki majburiy maydon yo'q.
• 401 Unauthorized — "siz kimsiz? Avval kiring". Kimligingiz tekshirilmagan. Kim ekanini tekshirish autentifikatsiya (authentication) deyiladi — login va parol shu ishni qiladi.
• 403 Forbidden — "sizni taniymiz, lekin bunga ruxsatingiz yo'q". Masalan, oddiy o'quvchi admin sahifasiga kirmoqchi. Nimaga ruxsat borligini tekshirish avtorizatsiya (authorization) deyiladi.
• 404 Not Found — "bunday resurs yo'q".
• 405 Method Not Allowed — "bu manzilda bunday metod ishlamaydi".
• 429 Too Many Requests — "juda ko'p so'rov yubordingiz, biroz kuting".

Haqiqiy misollar. GitHub API'ning shaxsiy sahifasini login qilmasdan so'raymiz:

curl -i https://api.github.com/user

HTTP/1.1 401 Unauthorized

{
  "message": "Requires authentication",
  ...
}

"Requires authentication" — "autentifikatsiya talab qilinadi", ya'ni avval kim ekaningizni isbotlang.

example.com da o'chirishga urinamiz:

curl -I -X DELETE https://example.com

HTTP/1.1 405 Method Not Allowed

Oddiy GET bilan -I qilsangiz, javobda allow: GET, HEAD sarlavhasi bor — server qaysi metodlarga ruxsat berishini oldindan aytib qo'ygan.

Mavjud bo'lmagan sahifa: curl -I https://example.com/yoq-sahifa → HTTP/1.1 404 Not Found.

4.5 5xx — server xatosi

• 500 Internal Server Error — "serverning ichida kutilmagan xato". Ko'pincha server kodidagi bug.
• 502 Bad Gateway — oraliq server (masalan, Nginx — so'rovlarni qabul qilib, asosiy dasturga uzatadigan server) asosiy dasturdan yaroqli javob ololmadi. Odatda asosiy dastur o'chib qolgan.
• 503 Service Unavailable — "server hozir band yoki texnik ishlar ketyapti".
• 504 Gateway Timeout — oraliq server asosiy dasturdan javobni kutib, vaqti tugadi.

5xx ko'rsangiz, mijoz tomonda tuzatadigan narsa yo'q — muammo serverda. Foydalanuvchi faqat keyinroq urinib ko'rishi mumkin.

Tekshirib ko'ring: Ali saytda to'g'ri parol bilan kirdi va /admin sahifasini ochdi. U admin emas. Qaysi kod to'g'ri: 401 mi yoki 403 mi?

5. Ko'p uchraydigan xatolar

5.1 PowerShell'da JSON body buziladi

Yuqoridagi PATCH buyrug'ini Windows PowerShell 5.1'da curl.exe bilan, xuddi o'sha -d '{"title":"Yangi"}' body'si bilan yozsangiz, server shunday javob beradi (qisqartirilgan):

SyntaxError: Unexpected token t in JSON at position 1
    at JSON.parse (<anonymous>)

Tarjimasi: "Sintaksis xatosi: JSON'ning 1-o'rnida kutilmagan t belgisi". PowerShell 5.1 ichki qo'shtirnoqlarni olib tashladi va serverga {title:Yangi} ketdi. JSON darsidan eslang: JSON'da kalitlar qo'shtirnoqda bo'lishi shart. 1-o'rinda " kutilgan edi, t keldi.

Yechim: JSON'ni faylga yozing (masalan, yangi.json) va --data "@yangi.json" bilan yuboring. Yoki bunday buyruqlarni Git Bash'da bajaring.

Qiziq tomoni: bu server javobida 500 qaytardi. Aslida bu mijoz xatosi — to'g'ri kod 400 bo'lishi kerak edi. Mashq serverlari ham doim ideal emas.

5.2 Hamma narsa uchun POST

Ba'zi dasturchilar o'qish uchun ham, o'chirish uchun ham POST ishlatadi. Server ishlaydi, lekin foydalar yo'qoladi: GET javoblari keshlanadi, qayta yuborish xavfsiz bo'ladi, boshqa dasturchi URL va metodga qarab nima bo'layotganini tushunadi. Har bir ish uchun o'z metodini tanlang.

5.3 Xato bo'lsa ham 200 qaytarish

HTTP/1.1 200 OK

{"xato": "Parol noto'g'ri"}

Status "hammasi yaxshi" deyapti, body esa "xato" deyapti. Brauzer, monitoring vositalari va boshqa dasturlar faqat kodga qarab "muvaffaqiyat" deb hisoblaydi. Xato bo'lsa — mos 4xx yoki 5xx kod qaytaring.

5.4 Ma'lumotni o'zgartiradigan GET

GET /buyurtmalar/15/ochir kabi havola yozish xavfli. Qidiruv robotlari va havola ko'rinishini yasaydigan dasturlar GET havolalarni o'zi ochadi — va buyurtmalarni o'chirib yuborishi mumkin. O'chirish uchun DELETE ishlating.

5.5 Sinovsiz 301

Brauzerlar 301 ni uzoq vaqt keshda saqlaydi. Xato yo'naltirish qo'ysangiz, uni serverda tuzatsangiz ham, foydalanuvchilar brauzeri eski yo'naltirishga ergashaveradi. Yo'naltirish to'g'riligiga ishonchingiz komil bo'lmasa, avval 302 bilan sinang.

6. Hujumchi nigohi

Status kodlari va javoblar ham hujumchiga ma'lumot beradi.

• Server ichki tuzilishi oshkor bo'lishi. PowerShell'dagi buzilgan JSON javobini eslang: at JSON.parse ... qatorlari — server dasturining ichki xato izi. Undan hujumchi server qaysi texnologiyada yozilganini va qaysi kutubxonalar ishlatilganini biladi, keyin shu kutubxonalarning ma'lum zaifliklarini qidiradi. To'g'ri yo'l: foydalanuvchiga qisqa xabar ({"xato": "JSON noto'g'ri"}), batafsil ma'lumot esa faqat server logida.
• 404 va 403 farqidan foydalanish. /admin — 403, /yoq-sahifa — 404 qaytsa, hujumchi qaysi yashirin sahifalar mavjudligini bilib oladi. Shuning uchun GitHub boshqalarning yopiq repozitoriylariga 404 qaytaradi, 403 emas — "bunday narsa bor" degan ma'lumot ham berilmaydi.
• Parolni URL'da yuborish. GET /kirish?parol=12345 — parol brauzer tarixida, server loglarida va yo'ldagi vositalarda saqlanib qoladi. Maxfiy ma'lumot faqat POST body'sida va faqat HTTPS orqali yuboriladi.
• Cheksiz urinishlar. Hujumchi parolni million marta taxmin qilishga urinadi. Server bir foydalanuvchidan kelgan juda ko'p urinishga 429 Too Many Requests qaytarib, uni to'xtatadi.

7. Mashqlar

1-mashq (oson): Status kodini tanlang

Har bir vaziyat uchun eng mos status kodini yozing:

1. Yangi foydalanuvchi ro'yxatdan o'tdi va bazaga yozildi.
2. Foydalanuvchi mavjud bo'lmagan /haqida-eski sahifasini ochdi.
3. Server kodida xato bo'lib, dastur qulab tushdi.
4. Login qilmagan foydalanuvchi "Mening buyurtmalarim" sahifasini so'radi.
5. Sayt http dan https ga butunlay o'tdi.

2-mashq (o'rta): Choyxona API'si

Choyxona ilovasi uchun metod va path'ni tanlang. Resurs — /taomlar.

1. Menyudagi hamma taomlarni ko'rsatish.
2. Menyuga yangi taom — "Manti" qo'shish.
3. 7-taomning faqat narxini o'zgartirish.
4. 7-taomni menyudan olib tashlash.

3-mashq (qiyin): Kodlarni ovlang

Git Bash'da har bir buyruqni ishga tushiring va status kodini yozing. Keyin nega aynan shu kod kelganini tushuntiring.

curl -s -o /dev/null -w "%{http_code}\n" http://github.com
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/yoq
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE https://example.com
curl -s -o /dev/null -w "%{http_code}\n" https://api.github.com/user
curl -s -o /dev/null -w "%{http_code}\n" -L http://github.com

Ishora: -L — yo'naltirishga ergash.

301
404
405
401
200

8. Real ishda

• REST API. Backend'da resurslar va metodlar aynan shu darsdagidek bog'lanadi: GET /taomlar, POST /taomlar, PATCH /taomlar/7. Bu uslub REST deb ataladi, uni REST darsida chuqur o'rganamiz.
• Frontend'da xatolarni ko'rsatish. 401 bo'lsa — login sahifasiga yuborasiz, 404 bo'lsa — "topilmadi" sahifasini, 5xx bo'lsa — "keyinroq urinib ko'ring" xabarini ko'rsatasiz.
• Monitoring. Kompaniyalarda 5xx javoblar soni kuzatib boriladi. Ular birdan ko'paysa, navbatchi dasturchiga xabar ketadi.
• SEO. Sayt manzillari o'zgarsa, eski URL'lardan 301 qo'yiladi — aks holda Google'dagi o'rinlar yo'qoladi.
• Intervyu savollari: "PUT va PATCH farqi?", "Idempotentlik nima?", "401 va 403 farqi?" — deyarli har bir backend intervyusida.

Xulosa

• Metod — nima qilmoqchimiz: GET o'qiydi, POST yaratadi, PUT to'liq almashtiradi, PATCH qisman o'zgartiradi, DELETE o'chiradi.
• Xavfsiz metodlar (GET, HEAD) hech narsani o'zgartirmaydi. Idempotent metodlarni (GET, PUT, DELETE) qayta yuborish xavfsiz, POST ni esa yo'q.
• Status kodining birinchi raqami asosiy ma'noni beradi: 2xx — yaxshi, 3xx — boshqa joyga, 4xx — mijoz xatosi, 5xx — server xatosi.
• Eng muhimlari: 200, 201, 204, 301, 302, 304, 400, 401, 403, 404, 429, 500, 502, 503.
• curl -X — metod, -I — faqat sarlavhalar, -w "%{http_code}" — faqat status kodi, -L — yo'naltirishga ergashish.

Keyingi dars: HTTP sarlavhalari, MIME turlari, cookie va kesh — javob turini, keshni va "kimligingiz"ni boshqaradigan sarlavhalar.