OkHttp — یہ کیا ہے، خصوصیات اور HTTP کلائینٹ کا آرکیٹیکچر

OkHttp کیا ہے؟

OkHttp Java، Android اور Kotlin کے لیے ایک موثر HTTP کلائینٹ ہے، جسے Square کمپنی نے تیار کیا ہے۔ لائبریری HTTP/2، SPDY، WebSocket اور نیٹورک ناکامیوں پر خودکار کنیکشن بحالی کے ساتھ HTTP درخواستوں کو انجام دینے کے لیے ایک نشیب سطحی API فراہم کرتی ہے۔

OkHttp 2013 میں ایک مستند HTTP کلائینٹ کی ضرورت کے جواب میں سامنے آیا جو HttpURLConnection کے مسائل کو حل کرتا — کنیکشن پول کی کمی، کمزور HTTP/2 تعاون اور نامناسب API۔ 2025 تک، OkHttp Android API سیسٹم سطح پر استعمال ہوتا ہے: OkHttp Android 4.4 (API 19) سے HttpURLConnection نفاذ میں شامل ہے۔

Google I/O 2024 کے مطابق، OkHttp Android اکو سیسٹم میں 70% سے زائد HTTP درخواستوں پر کارروائی کرتا ہے۔ یہ ممکن ہے کیونکہ OkHttp Retrofit، Apollo GraphQL، Firebase اور بہت سی دیگر لائبریریوں کے لیے ٹرانسپورٹ پرت کے طور کام کرتا ہے۔ ڈیولپرز OkHttp کی فعالیت کو واضح طور پر شامل کیے بغیر خودکار حاصل کرتے ہیں۔

OkHttp کیسے کام کرتا ہے

OkHttp کا آرکیٹیکچر اینٹرسیپٹر زنجیر پر بنا ہے۔ ہر درخواست اینٹرسیپٹروں کی ایک ترتیب سے گزرتی ہے جو درخواست، جواب میں ترمیم کر سکتے ہیں یا عمل کو روک سکتے ہیں۔ یہ آرکیٹیکچر Chain of Responsibility پیٹرن سے مشابہ ہے اور لچیلار توسیع پذیری کی اجازت دیتا ہے۔

جب کوئی ایپلیکیشن درخواست بھیجتی ہے، OkHttp درجے ذیل مراحل انجام دیتا ہے: DNS حل کرتا ہے، پول سے کنیکشن منتخب کرتا ہے، TLS مصافحہ کھولتا ہے، HTTP درخواست بھیجتا ہے، جواب وصول کرتا ہے اور اسے ایپلیکیشن میں واپس کرتا ہے۔ RealCall اندرونی کلاس ہے جو تخلیق سے تکمیل تک درخواست کے مکمل لائف سائکل کا انتظام کرتا ہے۔

OkHttp خودکار طور پر ری ڈائریکٹ (302, 301) کو ہینڈل کرتا ہے، نیٹورک ناکامیوں پر درخواستوں کو دوبارہ کوشش کرتا ہے، keep-alive پروٹیکال پر عمل کرتا ہے اور شفاف gzip کمپریشن کی مدد کرتا ہے۔ ڈیولپر کو ان کارروائیوں کے لیے کوڈ لکھنے کی ضرورت نہیں ہے — OkHttp انہیں سرور ہیڈرز کے بنیاد پر خودکار طور پر انجام دیتا ہے۔

HTTP/2 تعاون اور ملٹی پلیکسنگ

HTTP/2 ہیڈ آف لائن بلاکنگ (HTTP/1.1 کی خصوصیت) کے بغیر ایک واحد TCP کنیکشن پر ایک ساتھ متعدد درخواستیں بھیجنے کی اجازت دیتا ہے۔ OkHttp خودکار طور پر HTTP/2 استعمال کرتا ہے اگر سرور اسے سپورٹ کرتا ہے، اور ضرورت پڑنے پر شفاف طور پر HTTP/1.1 پر واپس آ جاتا ہے۔

HTTP/2 ملٹی پلیکسنگ موبائل ایپلیکیشنز کے لیے خاص طور پر اہم ہے، جہاں کنیکشن سیٹ اپ لیٹینسی (TCP + TLS) 100–300 ms ہو سکتی ہے۔ 10 متوالی کنیکشنز کے بجائے، OkHttp ایک استعمال کرتا ہے، جو غیر مستحکم کنیکشنز والے عام Android آلات پر کل لیٹینسی کو 40–60% تک کم کردیتا ہے۔

OkHttp کے اینٹرسیپٹر: Interceptor اور NetworkInterceptor

Interceptor ایک واحد طریقہ intercept(Chain) کے ساتھ ایک اینٹرفیس ہے، جو ایک درخواست وصول کرتا ہے، کارروائیاں کرتا ہے اور ایک جواب واپس کرتا ہے۔ اینٹرسیپٹر دو قسم کے ہوتے ہیں: ایپلیکیشن اینٹرسیپٹر (addInterceptor کے ذریعے شامل) اور نیٹورک اینٹرسیپٹر (addNetworkInterceptor)۔

ایپلیکیشن اینٹرسیپٹر HTTP درخواست کے بننے سے پہلے فعال ہوتے ہیں — وہ اصلی درخواست اور تمام تبدیلیوں کے بعد حتی جواب دیکھتے ہیں۔ نیٹورک اینٹرسیپٹر نیٹورک سطح پر فعال ہوتے ہیں: وہ gzip کمپریشن، Content-Length ہیڈر کا اضافہ، ری ڈائریکٹز اور دوبارہ کوششوں کے بعد درخواست دیکھتے ہیں۔ اگر جواب کیش سے فراہم کیا جاتا ہے تو نیٹورک اینٹرسیپٹر نہیں بلایا جاتا۔

اینٹرسیپٹروں کا عملی استعمال

عمل میں، OkHttp کے اینٹرسیپٹر تین اهم کام کرتے ہیں: اختیار دہی (Authorization ہیڈر کا اضافہ)، لاگنگ (ڈیباگنگ کے لیے HttpLoggingInterceptor) اور دوبارہ کوشش (نیٹورک ناکامیوں پر خودکار درخواست دهرائی)۔ متعدد اینٹرسیپٹروں کو ملا کر، ایپلیکیشن کی ہر HTTP کال میں کوڈ کو دوهرانے کے بغیر ایک مکمل درخواست پروسیسنگ پائپ لائن بنایا جا سکتا ہے۔

اینٹرسیپٹروں کو شامل کرنے کا حکم اہم ہے: سب سے پہلے شامل کیا گیا Interceptor داخل هوتے وقت سب سے پہلے اور نکلتے وقت سب سے آخر چلتا ہے۔ NetworkInterceptor کے لیے، حکم نیٹورک سٹاک کے ذریعے متعین ہوتا ہے۔ تجویز کردہ حکم: AuthInterceptor (ٹوکن شامل کرتا ہے)، LoggingInterceptor (درخواست لاگ کرتا ہے)، RetryInterceptor (ناکامی پر دوبارہ کوشش کرتا ہے)۔

HttpLoggingInterceptor کے ذریعے لاگنگ

نیٹورک درخواستوں کو ڈیباگ کرنے کے لیے، HttpLoggingInterceptor استعمال کیا جاتا ہے — Square کا ایک تیار اینٹرسیپٹر۔ یہ طریقہ، URL، ہیڈرز اور درخواست/جواب کا بوڈی لاگ کرتا ہے۔ لاگنگ کی سطح: BASIC (طریقہ + URL + کوڈ)، HEADERS (ہیڈرز کے ساتھ) اور BODY (مکمل درخواست اور جواب)۔ BODY ترقی کے دوران مفید ہے لیکن حفاظت اور کارکردگی کی وجوہات سے پیداوش میں ناقابل کر دیا جاتا ہے۔

Kotlin میں OkHttp کوڈ کی مثالیں

OkHttp استعمال کرتے ہوئے ایک بنیادی GET درخواست پر غور کریں۔ سب سے پہلے، OkHttpClient بنایا جاتا ہے — ایک بھاری آبجیکٹ جو ایک بار بنایا جاتا ہے اور دوبارہ استعمال ہوتا ہے۔ پھر URL کے ساتھ ایک Request بنائی جاتی ہے، اور درخواست execute کے ذریعے هم آہنگ یا enqueue کے ذریعے غیر هم آہنگ انجام دی جاتی ہے۔

val client = OkHttpClient.Builder()
    .connectTimeout(15, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .build()

val request = Request.Builder()
    .url("https://api.github.com/users/octocat")
    .header("Accept", "application/vnd.github.v3+json")
    .build()

val response = client.newCall(request).execute()
println(response.body()?.string())

غیر هم آہنگ انجام کے لیے، enqueue طریقہ استعمال کیا جاتا ہے، جو ایک Callback قبول کرتا ہے۔ OkHttp درخواست کو پس زمینہ ثریڈ میں انجام دیتا ہے اور نتیجہ اسی ثریڈ پر کال بیک میں واپس کرتا ہے۔ Android کے مین ثریڈ پر جانے کے لیے، Handler یا کوروٹینز استعمال کریں۔

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(
        call: Call, e: IOException
    ) {
        println("درخواست ناکام ہوئی: ${e.message}")
    }

    override fun onResponse(
        call: Call, response: Response
    ) {
        println(response.body()?.string())
    }
})

اختیار دہی کے لیے اینٹرسیپٹر شامل کرنا

ایک کسٹم Interceptor ہر درخواست میں Bearer ٹوکن شامل کرتا ہے۔ اینٹرسیپٹر Authorization ہیڈر کی موجودگی چیک کرتا ہے، اور اگر ٹوکن ابھی تک مقرر نہیں ہوا تو اسے ذخیرہ سے شامل کرتا ہے۔ 401 جواب پر، اینٹرسیپٹر Authenticator کے ذریعے ٹوکن کو تازہ کر سکتا ہے۔

class AuthInterceptor(
    private val tokenProvider: () -> String?
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val originalRequest = chain.request()
        val token = tokenProvider.invoke()
        val request = originalRequest.newBuilder()
            .header("Authorization", "Bearer $token")
            .build()
        return chain.proceed(request)
    }
}

OkHttp میں کنیکشن پول اور کیشنگ

کنیکشن پول (ConnectionPool) OkHttp کی ایک کلیڈی بہترین ہے جو متعدد درخواستوں کے لیے TCP کنیکشنز کو دوبارہ استعمال کرنے کی اجازت دیتی ہے۔ ہر درخواست کے لیے نیا ساکیٹ بنانے کے بجائے، OkHttp پیفر طور پر 5 منٹ کے لیے ادھر سے 5 غیر فعال کنیکشنز محفوظ کرتا ہے، اور ایک ہی میزبان کو دہرائی درخواستوں کی لیٹینسی کو 30–70% تک کم کردیا ہے۔

جوابات کی کیشنگ Cache کلاس کے ذریعے نفاذ کی جاتی ہے۔ کیشنگ فعال کرنے کے لیے، OkHttpClient.Builder میں ڈائرکٹری اور انتہائی حجم متعین کریں۔ OkHttp خودکار طور پر Cache-Control، Expires اور ETag ہیڈرز کے مطابق GET جوابات کو کیش کرتا ہے، اور اگر وہ فرسودہ نہیں ہیں تو بغیر نیٹورک درخواست کیش کردہ ڈیٹا واپس کرتا ہے۔

val cacheDir = File(context.cacheDir, "http-cache")
val cache = Cache(cacheDir, 10L * 1024 * 1024)

val client = OkHttpClient.Builder()
    .cache(cache)
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

پول اور کیش کی مناسب ترتیب خاص طور پر ایسی ایپلیکیشنز کے لیے اہم ہے جو اکسر درخواست کرتی ہیں — خبروں کے فیڈز، چیٹس، ڈیٹا اپ ڈیٹسیں۔ پول کے بغیر، ہر TCP کنیکشن کو تین طرفہ مصافحہ (SYN، SYN-ACK، ACK) اور ممکنہ TLS مصافحہ (2–3 راؤنڈ ٹرپز) کی ضرورت ہوتی ہے، جو ہر درخواست میں 100–500 ms کا اضافہ کرتا ہے۔

OkHttp RealWebSocket کلاس کے ذریعے WebSocket کو بھی سپورٹ کرتا ہے۔ ایک WebSocket کنیکشن HTTP مصافحہ (101 Switching Protocols) کے ذریعے قائم ہوتا ہے اور پھر دو طرفہ پروٹیکال پر سوئچ کرتا ہے۔ OkHttp کنیکشن کو زندہ رکھنے کے لیے خودکار طور پر ping فریمز بھیجتا ہے اور منقطع ہونے پر دوبارہ منصل ہوتا ہے۔ OkHttp کا WebSocket wss://echo.websocket.org جیسے معیاری اینڈ پوائنٹس کے ساتھ مطابق ہے۔

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

ہر درخواست کے لیے OkHttpClient بنانا سب سے عام غلطی ہے۔ OkHttpClient میں ایک کنیکشن پول، کیش اور ثریڈ پول ہوتا ہے۔ ہر درخواست کے لیے نیا انسٹنس بنانا نہ صرف میمری ضائع کرتا ہے بلکہ کنیکشن دوبارہ استعمال کے فائدے کو بھی کھتم کردیا ہے۔ OkHttpClient کو DI کنٹینر کے ذریعے ایک سنگلٹن ہونا چاہیے۔

Response.body() کو بند کرنے سے غفل وسائل کے رساو کا سبب بنتا ہے۔ ResponseBody میں ایک InputStream ہوتا ہے جسے پڑھنے کے بعد بند کرنا ضروری ہے۔ اگر body().string() یا body().bytes() استعمال کیا جاتا ہے، OkHttp خودکار طور پر سٹریم کو بند کر دیتا ہے، لیکن body().byteStream() یا body().charStream() پڑھنے پر finally بلاک میں واضح close() کو بلانا ضروری ہے۔

ٹائم آؤٹ ہینڈلنگ کی کمی ایک اور مسؤلہ ہے۔ پیفر طور پر، OkHttp کا connectTimeout 10 سیکنڈ، readTimeout 10 سیکنڈ اور writeTimeout 10 سیکنڈ ہے۔ غیر مستحکم کنیکشنز والی موبائل ایپلیکیشنز کے لیے، connectTimeout 15–30 سیکنڈ اور readTimeout 15–30 سیکنڈ مقرر کرنے کی سفارش کی جاتی ہے، ورنہ کمزور سیگنل کے ساتھ صارف بہت دیر انتظار کرے گا۔