Ktor: یہ کیا ہے، غیر ہم وقت ساز HTTP کلائنٹ کی خصوصیات

Ktor کیا ہے؟

Ktor JetBrains کی طرف سے بنایا گیا Kotlin میں غیر ہم وقت ساز سرور اور کلائنٹ ایپلیکیشنز بنانے کے لیے ایک فریم ورک ہے۔ Ktor Client فریم ورک کا کلائنٹ سائیڈ حصہ ہے، جو Kotlin coroutines، ملٹی پلیٹ فارم (JVM، Native، JS) اور ماڈیولر پلگ ان پر مبنی فن تعمیر کے مکمل سپورٹ کے ساتھ HTTP کلائنٹ فراہم کرتا ہے۔

Ktor 2018 میں Kotlin-first پروجیکٹس کے لیے Retrofit اور OkHttp کے متبادل کے طور پر سامنے آیا۔ Retrofit کے برعکس، جس نے اینوٹیشنز کے ساتھ Java طریقہ کار کو پورٹ کیا، Ktor Client درخواست کنفیگریشن کے لیے Kotlin DSL استعمال کرتا ہے — بغیر اینوٹیشنز اور ریفلیکشن کے۔ یہ کوڈ کو Kotlin ڈیولپرز کے لیے زیادہ پڑھنے کے قابل اور ٹائپ سیف بناتا ہے۔

2024 Kotlin Multiplatform سروے کے مطابق، Ktor Client 35% Kotlin Multiplatform Mobile (KMM) پروجیکٹس میں استعمال ہوتا ہے، جو اسے Kotlin کمیونٹی میں OkHttp کے بعد دوسرا سب سے مقبول HTTP کلائنٹ بناتا ہے۔ Ktor ان پروجیکٹس میں ترجیح دی جاتی ہے جہاں ملٹی پلیٹ فارم سپورٹ اور Kotlin ایکو سسٹم کے ساتھ مقامی انضمام اہم ہو۔

Ktor Client کیسے کام کرتا ہے

Ktor Client کا فن تعمیر پلگ ان کی پائپ لائن پر مبنی ہے۔ ہر درخواست انسٹال شدہ پلگ ان کے ایک سلسلے سے گزرتی ہے جو درخواست، جواب کو تبدیل کر سکتے ہیں یا ضمنی کارروائیاں انجام دے سکتے ہیں — لاگنگ، کمپریشن، سیریلائزیشن، تصدیق۔

HttpClient { } DSL بلاک کے ذریعے HTTP کلائنٹ بناتے وقت، آپ انجن (OkHttp، Android، CIO، Darwin) کی وضاحت کرتے ہیں اور پلگ ان انسٹال کرتے ہیں۔ ہر انجن ایک مخصوص پلیٹ فارم کے لیے نچلی سطح کی درخواست بھیجنا لاگو کرتا ہے: Android پر OkHttp انجن استعمال ہوتا ہے، iOS پر — Darwin (URLSession)، Desktop پر — CIO (Coroutine I/O)۔ HttpClient موجودہ پلیٹ فارم کے لیے خود بخود بہترین انجن منتخب کرتا ہے۔

Ktor Client میں ایک درخواست ایک suspend فنکشن کے ذریعے عمل میں لائی جاتی ہے، جس کا مطلب coroutines کے ساتھ مکمل انضمام ہے۔ کوئی کال بیکس نہیں، کوئی RxJava یا LiveData نہیں — صرف suspend کے ساتھ ترتیب وار کوڈ جو تھریڈ کو بلاک کیے بغیر غیر ہم وقت ساز کام کرتا ہے۔

درخواست پروسیسنگ پائپ لائن

Ktor پائپ لائن مراحل پر مشتمل ہے: پہلے درخواست انسٹال شدہ پلگ ان سے گزرتی ہے (مثلاً JSON کے لیے ContentNegotiation، لاگز کے لیے Logging)، پھر انجن HTTP درخواست پر عملدرآمد کرتا ہے، اور جواب ڈی سیریلائزیشن کے لیے دوبارہ پلگ ان سے گزرتا ہے۔ ہر پلگ ان ایک suspend فنکشن ہے جو پائپ لائن coroutine میں عملدرآمد کرتا ہے۔

Ktor پائپ لائن کا ایک اہم فائدہ مشروط پروسیسنگ کرنے کی صلاحیت ہے۔ ایک پلگ ان URL یا درخواست کے ہیڈرز کو چیک کر سکتا ہے اور اگر شرط پوری نہ ہو تو پروسیسنگ چھوڑ سکتا ہے۔ مثال کے طور پر، gzip کے ساتھ ContentEncoding صرف ان جوابات پر لاگو ہوتا ہے جن میں Content-Encoding: gzip ہیڈر ہو، اور Auth صرف محفوظ اینڈ پوائنٹس کے لیے متحرک ہوتا ہے، عوامی APIs کو متاثر کیے بغیر۔

یہ پائپ لائن طریقہ کار آپ کو پلگ ان کو لچکدار طریقے سے یکجا کرنے کی اجازت دیتا ہے: آپ JSON کے ساتھ ContentNegotiation انسٹال کر سکتے ہیں، Bearer ٹوکن کے ساتھ Auth شامل کر سکتے ہیں، ContentEncoding کمپریشن اور HttpTimeout کو فعال کر سکتے ہیں — اور یہ سب صحیح ترتیب میں مل کر کام کریں گے۔ پلگ ان انسٹالیشن کی ترتیب اہم ہے: پہلا انسٹال کردہ پلگ ان دوسروں سے پہلے درخواست پر کارروائی کرے گا۔

Ktor Client پلگ ان

پلگ ان Ktor کا ماڈیولر ایکسٹینشن سسٹم ہے، جو Retrofit اینوٹیشنز اور OkHttp انٹرسیپٹرز کی جگہ لیتا ہے۔ ہر پلگ ان ایک مخصوص کام حل کرتا ہے اور HttpClient بلاک میں install() فنکشن کے ذریعے انسٹال کیا جاتا ہے۔ Ktor بلٹ ان پلگ ان فراہم کرتا ہے اور کسٹم پلگ ان بنانے کی بھی اجازت دیتا ہے۔

کسٹم پلگ ان

مخصوص کاموں کے لیے، createClientPlugin کے ذریعے ایک کسٹم پلگ ان بنایا جاتا ہے۔ پلگ ان درخواست (onRequest)، جواب (onResponse) کو روک سکتا ہے یا غلطیوں (onError) کو ہینڈل کر سکتا ہے۔ یہ OkHttp کے Interceptor کو مکمل طور پر بدل دیتا ہے، لیکن ٹائپ شدہ Kotlin API اور suspend فنکشن سپورٹ کے ساتھ۔

کسٹم پلگ ان میٹرکس شامل کرنے، خودکار دوبارہ کوشش منطق، درخواست ٹریسنگ یا اینڈ پوائنٹس کی A/B جانچ کے لیے آسان ہیں۔ OkHttp انٹرسیپٹرز کے برعکس، Ktor پلگ ان Kotlin میں لکھے جاتے ہیں اور coroutine سیاق و سباق میں چلتے ہیں، غلطی اور ٹائم آؤٹ ہینڈلنگ کو آسان بناتے ہیں۔

درخواستوں کی ڈیبگنگ کے لیے، Logging پلگ ان ALL، HEADERS یا BODY لیول کے ساتھ استعمال ہوتا ہے۔ Logging طریقہ، URL، حیثیت، ہیڈرز اور درخواست اور جواب کا باڈی آؤٹ پٹ کرتا ہے۔ OkHttp کے HttpLoggingInterceptor کے برعکس، Ktor Logging غیر ہم وقت ساز کام کرتا ہے اور کنفیگریشن تبدیل کرنے کے لیے ایپلیکیشن کو روکے بغیر لاگ لیول (ERROR، WARN، INFO، DEBUG) کے مطابق فلٹر کرنے کے لیے کنفیگر کیا جا سکتا ہے۔

Kotlin میں Ktor Client کوڈ کی مثالیں

Ktor Client استعمال کرتے ہوئے بنیادی GET درخواست دیکھتے ہیں۔ JSON کے لیے ContentNegotiation پلگ ان انسٹال کرکے ایک HttpClient بنایا جاتا ہے۔ درخواست suspend فنکشن get() کے ذریعے عمل میں لائی جاتی ہے، اور نتیجہ خود بخود ڈیٹا کلاس میں ڈی سیریلائز ہو جاتا ہے۔

data class User(
    val login: String,
    val id: Int,
    val avatarUrl: String
)

val client = HttpClient {
    install(ContentNegotiation) {
        json(Json {
            ignoreUnknownKeys = true
        })
    }
}

suspend fun getUser(): User {
    return client.get("https://api.github.com/users/octocat").body()
}

باڈی کے ساتھ POST درخواست کے لیے contentType() اور body() کے ساتھ post() فنکشن استعمال ہوتا ہے۔ Ktor انسٹال شدہ ContentNegotiation کے ذریعے آبجیکٹ کو خود بخود JSON میں سیریلائز کرتا ہے۔ DSL سٹائل کوڈ کو ترتیب وار اور پڑھنے کے قابل بناتا ہے۔

data class CreateRepo(
    val name: String,
    val description: String,
    val private: Boolean
)

suspend fun createRepo(): Unit {
    val repo = CreateRepo(
        name = "my-project",
        description = "Sample project",
        private = false
    )
    client.post("https://api.github.com/user/repos") {
        contentType(ContentType.Application.Json)
        setBody(repo)
    }
}

ٹائم آؤٹ اور ہیڈرز کی کنفیگریشن

HttpTimeout اور DefaultRequest کنفیگریشن کے لیے دو اہم پلگ ان ہیں۔ HttpTimeout وقت کی حدیں مقرر کرتا ہے، اور DefaultRequest تمام درخواستوں کے لیے ہیڈرز اور URL پیرامیٹرز متعین کرتا ہے، ہر کال میں کوڈ ڈپلیکیشن کو ختم کرتا ہے۔

val client = HttpClient {
    install(HttpTimeout) {
        connectTimeoutMillis = 15000
        requestTimeoutMillis = 30000
    }
    install(DefaultRequest) {
        url("https://api.github.com/")
        header("Accept", "application/json")
    }
}

Ktor ملٹی پلیٹ فارم سپورٹ

ملٹی پلیٹ فارم OkHttp اور Retrofit پر Ktor کا سب سے بڑا فائدہ ہے۔ Ktor Client JVM (Android، Server)، Native (iOS، macOS، Windows، Linux) اور JS (Browser) پر چلتا ہے۔ وہی HTTP کلائنٹ کوڈ بغیر تبدیلی کے تمام پلیٹ فارمز پر چلتا ہے، جو خاص طور پر Kotlin Multiplatform پروجیکٹس کے لیے قیمتی ہے۔

ہر پلیٹ فارم کے لیے، Ktor اپنا انجن استعمال کرتا ہے۔ Android پر، ڈیفالٹ طور پر OkHttp انجن استعمال ہوتا ہے، جو OkHttp ایکو سسٹم کے ساتھ مکمل مطابقت فراہم کرتا ہے۔ iOS پر، URLSession پر مبنی DarwinEngine استعمال ہوتا ہے۔ Server کے لیے — CIOEngine (Coroutine I/O)۔ انجن کو واضح طور پر متعین کیا جا سکتا ہے: HttpClient(OkHttp) { } یا HttpClient(Darwin) { }۔

انجن کا انتخاب کرتے وقت اس کی صلاحیتوں پر غور کریں: OkHttp انجن HTTP/2 اور کنکشن پولنگ کو سپورٹ کرتا ہے، DarwinEngine مقامی iOS نیٹ ورک انضمام اور بیک گراؤنڈ URLSession سیشن فراہم کرتا ہے، CIOEngine بیرونی انحصار کے بغیر ایک خالص coroutine نفاذ ہے۔ ویب اہداف کے لیے، JsEngine یا BrowserEngine استعمال ہوتا ہے، جو fetch API کے ذریعے کام کرتا ہے۔

تمام پلیٹ فارمز پر یکساں API کی بدولت، ڈیٹا لوڈ کرنے کا کوڈ Android، iOS اور Desktop پر ایک جیسا نظر آتا ہے۔ یہ Retrofit (Android) اور URLSession (iOS) پر علیحدہ نفاذ کے مقابلے KMM پروجیکٹس میں کوڈ ڈپلیکیشن کو 60–80% تک کم کرتا ہے۔ پلگ ان بھی بغیر تبدیلی کے تمام پلیٹ فارمز پر کام کرتے ہیں۔

Ktor کے ساتھ کام کرتے وقت عام غلطیاں

HttpClient کو بند کرنے کو نظرانداز کرنا Ktor میں ایک عام غلطی ہے۔ HttpClient Closeable کو لاگو کرتا ہے، اور ایپلیکیشن ختم ہونے پر client.close() کے ذریعے اسے بند کرنا ضروری ہے۔ Android میں، یہ Activity کے onDestroy() یا ViewModel.onCleared() میں کیا جاتا ہے۔ بند نہ کیا گیا کلائنٹ coroutines اور انجن تھریڈ لیک کا سبب بنتا ہے۔

غلط پلگ ان ترتیب درخواست پروسیسنگ کو توڑ سکتی ہے۔ مثال کے طور پر، ContentNegotiation کو DefaultRequest سے پہلے انسٹال کیا جانا چاہیے تاکہ مواد کی قسم صحیح طریقے سے لاگو ہو۔ Logging کو آخری میں انسٹال کرنے کی سفارش کی جاتی ہے تاکہ تمام تبدیلیوں کے بعد درخواست کے آخری ورژن کو لاگ کیا جا سکے۔ اگر پلگ ان غیر متوقع سلوک کریں تو ترتیب کے ساتھ تجربہ کریں۔

Suspend فنکشنز میں استثنا ہینڈلنگ کی کمی۔ Ktor نیٹ ورک کی غلطیوں کے لیے IOException اور HTTP 4xx اسٹیٹس کے لیے ClientRequestException پھینکتا ہے۔ get()، post() اور دیگر طریقوں کی ہر کال کے لیے try-catch بلاک لازمی ہے۔ ہر طریقہ میں try-catch کو ڈپلیکیٹ کیے بغیر گلوبل ایرر ہینڈلنگ کے لیے HttpClient بلاک میں HttpResponseValidator استعمال کریں۔