REST API: bu nima, HTTP metodlari va mobil ilovalarda ishlash prinsipi

REST API nima?

REST API (Representational State Transfer API) — 2000-yilda Roy Fielding tomonidan doktorlik dissertatsiyasida taklif qilingan arxitektura uslubi. U tarmoq protokollarini loyihalashtirish uchun cheklovlar va tamoyillar to'plamini belgilaydi. Ushbu cheklovlarga mos keladigan API RESTful deb ataladi. REST protokol yoki standart emas — bu mijoz va server o'rtasida ma'lumot almashish uchun mavjud protokollardan (asosan HTTP) foydalanadigan arxitektura yondashuvidir.

RESTning asosiy g'oyasi resursga yo'naltirilgan arxitekturadir. Serverda metodlarni chaqirish o'rniga (SOAP yoki RPCdagi kabi), mijoz resurslar bilan ishlaydi: ularning ro'yxatini oladi, yangilarini yaratadi, yangilaydi yoki o'chiradi. Har bir resurs soha ob'ektidir: foydalanuvchi, buyurtma, mahsulot, maqola. Resursning holati standartlashtirilgan formatda, odatda JSON orqali mijozga uzatiladi. Server so'rovlar o'rtasida mijozning holatini saqlamaydi — bu stateless tamoyili, RESTning asosiy talabidir.

REST APIning asosiy xususiyatlari:

• Stateless — mijozdan kelgan har bir so'rov uni qayta ishlash uchun barcha kerakli ma'lumotlarni o'z ichiga oladi
• Cacheable — server javoblari aniq ravishda keshlashtiriladigan yoki keshlashtirilmaydigan deb belgilanishi kerak
• Layered system — arxitektura oraliq serverlar, yuk balanslagichlari, proksilarni o'z ichiga olishi mumkin
• Uniform interface — HTTP metodlari, URL va status kodlari orqali yagona o'zaro aloqa interfeysi

REST arxitekturasining tamoyillari

REST Fielding tomonidan shakllantirilgan oltita arxitektura chekloviga asoslanadi. Ushbu cheklovlarga rioya qilish masshtablashuvchanlik, samaradorlik va integratsiya qulayligini kafolatlaydi. Har bir tamoyil taqsimlangan tizimlarning muayyan muammosini hal qiladi — keshlashtirish zaruratidan xavfsizlik talablarigacha. Keling, har bir tamoyilni batafsil ko'rib chiqaylik.

Uniform Interface tamoyili qo'shimcha ravishda to'rtta quyi cheklovni o'z ichiga oladi: resurslarni URI orqali identifikatsiya qilish, tasvirlar orqali resurslar bilan manipulyatsiya qilish, o'zini-o'zi tavsiflovchi xabarlar va HATEOAS (gipermedia dastur holatining dvigateli sifatida). Oxirgi quyi cheklov amaliyotda ko'pincha e'tibordan chetda qoladi — zamonaviy REST APIlarning aksariyati HATEOASni to'liq joriy qilmaydi va bu bunday API „haqiqiy” RESTfulmi yoki yo'qmi degan munozaralarga sabab bo'ladi.

Stateless tamoyili masshtablash uchun eng muhimlaridan biridir. Serverda sessiyalarning yo'qligi har qanday server nusxasi istalgan so'rovni qayta ishlashi mumkinligini anglatadi. Bu gorizontal masshtablashni soddalashtiradi: yuk balanslagichi orqasiga yangi serverlarni qo'shish kifoya. Mobil ilovalar uchun stateless, shuningdek, so'rov istalgan CDN serveriga yuborilishi mumkinligini anglatadi, bu global foydalanish imkoniyati uchun juda muhimdir.

RESTda HTTP metodlari

REST APIdagi har bir HTTP metodi resurs ustida muayyan operatsiyaga mos keladi: GET o'qish uchun, POST yaratish uchun, PUT to'liq yangilash uchun, PATCH qisman yangilash uchun, DELETE o'chirish uchun. Metodlarning idempotentligi asosiy xususiyatdir: GET, PUT, DELETE idempotentdir (takroriy bajarish bir xil natijani beradi), POST va PATCH esa yo'q. Bu tarmoq xatolarini qayta ishlashda muhimdir, chunki mijoz so'rov serverga yetib borganligini bilmaydi.

• GET — resurs yoki resurslar ro'yxatini olish. Idempotent, server holatini o'zgartirmaydi
• POST — yangi resurs yaratish. Idempotent emas, har bir chaqiruv yangi resurs yaratadi
• PUT — resursni to'liq almashtirish. Idempotent, takroriy chaqiruv birinchidan keyin holatni o'zgartirmaydi
• PATCH — resursni qisman yangilash. Qisman idempotent (amalga oshirishga bog'liq)
• DELETE — resursni o'chirish. Idempotent, takroriy o'chirish 404 qaytaradi, xato emas

HTTP status kodlari REST APIning ajralmas qismidir. Har bir kod muayyan ma'noga ega: 200 OK muvaffaqiyatli GET uchun, 201 Created POST uchun, 204 No Content javob tanasiz DELETE uchun, 400 Bad Request yaroqsiz ma'lumotlar uchun, 401 Unauthorized autentifikatsiya bo'lmaganda, 404 Not Found resurs topilmaganda. Status kodlaridan to'g'ri foydalanish API-ni o'zini-o'zi hujjatlashtiradigan qiladi va disk raskadrovkani soddalashtiradi.

Ma'lumot formatlari: JSON va boshqalar

JSON (JavaScript Object Notation) — REST APIda ma'lumot uzatishning asosiy formatidir. Uning mashhurligi soddaligi, inson o'qiy olishi va JavaScriptdagi mahalliy qo'llab-quvvatlash bilan izohlanadi. JSON Content-Type: application/json sarlavhasi bilan uzatiladi. Alternativlarga XML (hajmli, eskirgan), YAML (konfiguratsiya uchun qulay, API uchun kam) va Protocol Buffers (binar, yuqori yuklangan tizimlar uchun samarali) kiradi.

REST APIdagi JSON ob'ektining tuzilishi odatda id, type maydonlarini va resurs atributlarini o'z ichiga oladi. Kollektsiyalar uchun paginatsiya metama'lumotlariga ega JSON massivi ishlatiladi. Zamonaviy REST APIlar javoblarni tekshirish uchun JSON:API (jsonapi.org) yoki JSON Schema spetsifikatsiyasiga amal qiladi. Yagona ma'lumot formatidan foydalanish mijoz kutubxonalarini ishlab chiqishni va hujjatlarni yaratishni soddalashtiradi.

Foydalanuvchilar ro'yxati uchun JSON javob namunasi:

{
    "data": [
        {
            "id": 1,
            "name": "Anna Petrova",
            "email": "anna@example.com"
        }
    ],
    "meta": {
        "total": 42,
        "page": 1,
        "per_page": 10
    }
}

Ma'lumot uzatish formatini tanlash mobil ilova samaradorligiga ta'sir qiladi. JSON GZIP orqali 70–80% gacha siqiladi va bu uni aksariyat stsenariylar uchun maqbul qiladi. Katta hajmdagi ma'lumotlarga ega real vaqt ilovalari (striming, o'yinlar) uchun binar protokollarga o'tish yoki Protocol Buffers bilan birgalikda WebSocket'dan foydalanish tavsiya etiladi.

REST API so'rovlariga misollar

Mobil ilova tomonidan REST API bilan ishlashning amaliy misollarini ko'rib chiqaylik. Misol sifatida onlayn do'konda buyurtmalar bilan ishlash uchun API-ni olaylik. Har bir HTTP metodi uchun so'rov va kutilayotgan server javobi ko'rsatilgan. Misollar mobil ishlanmada qo'llaniladigan odatiy RESTful API tuzilmasini namoyish etadi.

GET — buyurtmalar ro'yxatini olish

Paginatsiya bilan foydalanuvchining barcha buyurtmalarini olish uchun so'rov. Javob buyurtma ob'ektlarining massivi va sahifalash navigatsiyasi uchun meta-ma'lumotlarni o'z ichiga oladi. Page va per_page parametrlari query string orqali uzatiladi.

// Retrofit interfeysi REST API uchun
interface OrderApi {
    @GET("api/v1/orders")
    suspend fun getOrders(
        @Query("page") page: Int = 1,
        @Query("per_page") perPage: Int = 20
    ): Response<OrderListResponse>
}

POST — yangi buyurtma yaratish

POST so'rovi orqali yangi buyurtma yaratish. Server 201 Created statusi va javob tanasida yaratilgan ob'ektni qaytaradi. Muhim: yaratish /api/v1/orders kollektsiyasiga amalga oshiriladi, aniq resursga emas — bu standart RESTful naqshidir.

@POST("api/v1/orders")
suspend fun createOrder(
    @Body order: CreateOrderRequest
): Response<OrderResponse>

// So'rov tanasi namunasi
data class CreateOrderRequest(
    val productId: String,
    val quantity: Int,
    val addressId: String
)

DELETE — buyurtmani o'chirish

Resursni o'chirish buyurtmaning aniq URLiga DELETE metodi bilan amalga oshiriladi. Muvaffaqiyatli o'chirish 204 No Content qaytaradi. DELETE idempotentligi shuni anglatadiki, xuddi shu URLga takroriy so'rov 404 Not Found qaytaradi va bu mijoz tomonida to'g'ri qayta ishlanadi.

@DELETE("api/v1/orders/{id}")
suspend fun deleteOrder(
    @Path("id") orderId: String
): Response<Unit>

// ViewModelda foydalanish
fun removeOrder(orderId: String) {
    viewModelScope.launch {
        val response = api.deleteOrder(orderId)
        if (response.isSuccessful) {
            showSuccess()
        }
    }
}

Ushbu misollar Android tomonida Retrofit va Kotlin Coroutines yordamida REST APIning odatiy tatbiqini namoyish etadi. iOS ilovalari uchun URLSession yoki Codable protokollari bilan birgalikda Alamofire kutubxonasi o'xshash rolni bajaradi. REST API tuzilishi platformadan qat'iy nazar bir xil bo'lib qoladi — faqat so'rovlarni bajarish usuli o'zgaradi.

RESTful API dizayni: amaliy tavsiyalar

Yuqori sifatli RESTful API loyihalashtirish dasturchilar uchun API-ni intuitiv qiladigan konventsiyalarga rioya qilishni talab qiladi. Resurslar ko'plikdagi otlar bilan nomlanishi kerak (/users, /orders, /products), HTTP metodlari operatsiyalarni aks ettirishi kerak, URLlar esa ierarxik tuzilmani ko'rsatishi kerak. Xatolar kod va xabar bilan standartlashtirilgan JSON qaytarishi kerak, shunchaki HTTP status emas. Ushbu konventsiyalarga rioya qilish yangi dasturchilar uchun kirish chegarasini pasaytiradi va integratsiyani soddalashtiradi.

• Resurslarni nomlash — ko'plik, kebab-case: /api/v1/user-orders, /api/v1/getUserOrders emas
• Filtrlash va saralash — query parametrlari orqali: ?status=active&sort=created_at:desc
• Paginatsiya — katta to'plamlar uchun cursor-based, kichiklar uchun page-based
• Versiyalash — URL (/api/v2/) yoki Accept-Version sarlavhasi orqali
• Xatolar — yagona format: { "error": { "code": "VALIDATION_ERROR", "message": "..." } }
• Rate limiting — X-RateLimit-Remaining va Retry-After sarlavhalari

REST API loyihalashtirishda keng tarqalgan xatolardan biri resurslarning haddan tashqari ichki joylashuvidir. /users/1/orders/5/items/3 o'rniga query parametrlari bilan tekis tuzilmadan foydalanish yaxshiroq: /items?order_id=5&user_id=1. Bu keshlashtirishni soddalashtiradi, serverda uzun yo'llarni qo'llab-quvvatlashni talab qilmaydi va hujjatlashtirishni osonlashtiradi. Tekis arxitektura kelajakda GraphQLga o'tishda graph-based so'rovlar bilan ham yaxshiroq mos keladi.

REST API xavfsizligi autentifikatsiya (JWT, OAuth 2.0) va resurs darajasidagi avtorizatsiya orqali amalga oshiriladi. Har bir so'rov foydalanuvchining so'ralgan resursga kirish huquqi bor yoki yo'qligini tekshirishi kerak. HTTPS majburiydir – shifrlashsiz tokenlar va ma'lumotlar ochiq matn shaklida uzatiladi. Mobil ilovalar uchun tokenlarni xavfsiz olish uchun PKCE (Proof Key for Code Exchange) bilan OAuth 2.0 dan foydalanish tavsiya etiladi.

Versiyalash va keshlashtirish

REST API ni versiyalash o'zgarishlar paytida orqaga qarab muvofiqlikni saqlash uchun zarurdir. Eng keng tarqalgan yondashuvlar: URLdagi versiya (/api/v1/orders), sarlavhadagi versiya (Accept: application/vnd.myapi.v1+json) va query parametridagi versiya (?api_version=1). URL versiyalash eng mashhur usuldir, chunki u jurnallar va hujjatlarda aniq ko'rinadi. Biroq bu RESTning yagona resurs URL tamoyilini buzadi.

REST APIda keshlashtirish HTTP Cache-Control, ETag va Last-Modified sarlavhalari orqali amalga oshiriladi. Keshlashtiriladigan deb belgilangan GET so'rovlari serverga murojaat qilmasdan brauzer yoki proksi keshegidan xizmat ko'rsatishi mumkin. Mobil ilovalar uchun keshlashtirish ayniqsa muhimdir — bu trafik sarfini kamaytiradi va zaif aloqada oldin yuklangan ma'lumotlarni ko'rsatishni tezlashtiradi. ETag javob mazmunining xeshidir: mijoz uni If-None-Matchda yuboradi, server esa ma'lumotlar o'zgarmagan bo'lsa 304 Not Modified qaytaradi.

REST APIning zamonaviy alternativlariga GraphQL (mijoz tomonidan moslashuvchan ma'lumot tanlash) va gRPC (mikroxizmatlar uchun HTTP/2 ustidagi binar protokol) kiradi. Biroq REST soddaligi, universalligi va keng vositalar qo'llab-quvvatlashi tufayli ochiq APIlar uchun asosiy standart bo'lib qolmoqda. REST va alternativlar o'rtasidagi tanlov loyihaning aniq talablariga bog'liq: so'rovlarning murakkabligi, ma'lumotlar hajmi, real vaqt yangilanish talablari.